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An  MCM  Concurrent 
Engineering  Software  Tool 
Market  Study 


Section  1  —  Executive  Summary 

Market  Study  Overview 

This  Market  Study  has  been  developed  for  the  Advanced  Research  Projects 
Agency  (ARPA)  under  the  DICE  program  contract  number  MDA972-92-C-0022. 

This  Market  Study  is  focused  on  the  concurrent  engineering  software  technology 
developed  under  the  DICE  program  that  uses  the  Rensellaer  Object  Storage 
Environment  (ROSE).  Referred  to  as  "CHOICE”,  this  technology  has  been 
developed  by  the  l^croelectronics  Computer  and  Technology  Corporation 
(MCC)  in  cooperation  with  Harris  Electronic  Design  Automation,  Inc.  (Harris 
EDA),  the  Harris  Government  Aerospace  Systems  Division  of  Harris 
Corporation  (Harris  GASD),  and  STEP  Tools,  Incorporated  (STEP  Tools). 

Objective 

The  objective  of  this  Market  Study,  based  on  a  survey  of  end-user  reqtdrements, 
is  to  determine  how  CHOICE  could  be  further  developed  and  then  distributed  to 
the  commercial  market. 

To  reach  our  stated  objective,  an  assessment  of  the  current  CHOICE  technology, 
how  this  techndogy  could  be  positioned  in  the  commercial  Electronic  Design 
Automation  (EDA)  market  place,  and  a  proposed  product-market  launch  plan 
are  included. 
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Market  Study  Summary 

The  conduaions  reached  in  dus  Market  Study  are  based  on  a  combination  of 

inputs: 

•  A  review  and  analysis  by  senior  software  developers  of  the  CHOICE 
tedmdogy. 

•  Interviews  with  ARPA  contractors  who  are  developing  complementary 
technology  for  concurrent  engineering  envirorunents. 

•  End-user  reactions  to  demcmstrations  of  CHOICE. 

•  A  commissioned  case  study  report  submitted  by  Harris  GASD,  describing 
dwir  implementation  of  concurrent  engineering  inethods  for  MCM  design. 

•  A  telemarketing  survey  of  systems  electronic  companies  who  represent 
potential  end-users. 

•  An  analysis  of  the  EDA  software,  MCM  technology,  and  concurrent 
engineering  markets. 

•  The  technology  and  business  experieiKe  of  the  Market  Study  Program  Team. 

These  ii^uts  are  discussed  in  detail  throughout  this  Market  Study.  They  have 

been  compiled,  reviewed,  and  debated  with  the  following  criteria  in  mind; 

•  Determine  areas  where  CHOICE  could  be  enhanced  and  modified  to  provide 
functions  that  address  the  concerns  that  were  indicated  by  the  end-users. 

•  Propose  a  product  positioning  of  CHOICE  in  the  EDA  market. 

•  Forecast  the  potential  market  for  CHOICE  and  die  estimated  cost  of 
introducing  CHOICE  to  the  commercial  market. 

•  Pr(^>ose  a  product  launch  plan. 


Summary  of  Conclusions 

The  data  collected  in  this  Market  Study  identifies  a  significant  end-user  demand 
for  concurrent  engineering  environments  for  MCM  software  tools.  The  com¬ 
mercially  available  systems  do  not  satisfy  die  end-users  needs  as  indicated  by 
the  large  satisfaction  gaps  for  MCM  design  data  categories  in  our  telemarketing 
survey. 

Access  to  chip  data,  bi-directional  translation  of  data,  neutral  data  storage,  and 
data  transfer  standards  were  identified  as  die  top  four  areas  that  are  not  being 
addressed  in  a  satisfactory  manner.  Respondents  to  our  telemarketing  survey 
offered  diese  comments: 


"(EDA)  Vendors  prefer  using  their  oum  internal  formats  instead  of  establishing 
standards." 

"Using  existing  standards  for  other  product  domains  that  don 't  meet  MCM  needs. " 


ARPA  Market  Study — Executive  Summary 


Section  1  •  Page  2 


"Advent  of  STEP  standards  unit  require  the  delivery  of  STEP  for  MCM  products. " 


Regarding  tiheir  MCM  design  environments; 

"H^‘t  gone  all  too  smooth." 

"N<d  much  there.  Foundries  just  beginning  to  build  kits. " 


Regarding  STEP/PDES: 

"Has  the  rigftt  infbrmation  content,  but  not  useful  until  vendors  support  it. " 


Several  technology  areas  must  be  enhanced  to  ctmdition  CHOICE,  or  a  product 
derivative  of  CHOICE,  to  become  a  commercially  acceptable  product.  The  con¬ 
tinued  support  of  ARPA  remaiiu  a  critical  aspert  of  any  business  plan.  ARPA 
support  and  its  erulorsement  of  CHOICE  ensure  that  the  technology  is 
furdier  developed,  provide  credibility  for  the  technology,  and  will  stimulate 
end-user  involvement  in  the  testir^  and  evaluation  of  the  technology. 

The  market  c^portunity  is  growing  rapidly  as  systems  electronic  companies 
ad(^  MCM  technology  into  dteir  rwxt  gerteration  products.  The  data  collected 
for  dtis  Market  Study  strongly  support  a  forecast  for  a  doubling  of  MCM 
technology-related  expenditures  in  1994. 

Eitd-users  of  MCM  design  environments  and  tools  have  invested  -  and  continue 
to  invest  -  in  the  development  of  costly  manual  processes  (in  terms  of  time, 
mmey,  and  huirum  resources)  to  ctnnpensate  for  die  missing  functions  that  are, 
or  could  potentially  be  provided  by  the  CHOICE  concurrent  engineering 
environment. 

CHOICE  could  further  be  developed  to  create  a  commercial-quality  concurrent 
er^ineering  environment  that  MCM  design  companies  could  employ  in  con¬ 
junction  with  existing  MCM  design  tools  and  environments.  Specifically,  the 
areas  suitable  fot  furdier  development  include: 

1.  Furdier  devel<^  die  CHOICE  technology  to  commercial  quality  levels  by 
adding  test  vehicles  representing  multiple  MCM  process  technologies, 
version  control  functions,  and  security  features. 

2.  Develop  product  models  and  EXPRESS  representations  for  MCM  technology 
selection.  Design  Kits,  and  manufacturing  optimization. 

3.  Enhance  CHOICE  with  the  addition  of  the  Design  Integrity  Management 
software  diat  validates  EDA  data  collected  horn  multiple  applications. 

4.  Enhance  CHOICE  by  adding  support  of  the  EXPRESS  models  for  standard 
data  interchange  formts  including  die  Electronic  Design  Interchange  Format 
(EDIF),  die  Logic  Modeling  Corporation  (LMC)  Die  Information  Exchange 
(DIE)  Format,  and  the  CAx  Interface  Alliance  data  definition  for  MCM 
Foundries. 
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5.  Create  a  graphical,  open  applications  programming  environment  that  allows 
end-users  the  opportunity  to  customize  the  integration  of  the  DICE 
environment  with  currently  existing  and  future  tool  selections. 

6.  Enhance  the  concurrent  engineering  environment  to  include  design-for-test, 
automatic  test  program  generation,  automatic  test  validation  software  and 
support  for  MC^  diagnostic  testing. 

7.  Integrate  an  MCM  Design  Optimization  software  that  adds  multi-level 
system  floorplanning  and  partitioning  wifltin  the  CHOICE  environment. 

8.  Integrate  a  parts-and-materials  numagement  application  into  CHOICE. 

9.  Enhance  CHOICE  to  allow  for  foe  ctmcurrent  operaticm  of  electronic  design 
simulation  tools,  foereby  allowing  for  mixed  si^ud  and  chip  and  MCM  level 
simulatiim  of  coii:^>lex  circuits. 

10.  bitegrate  CAE  applications,  including  multiple  digital  and/or  analog  simu¬ 
lation  tools,  to  promote  multi-level  and  mixed  signal  system  simulation. 
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Section  2  —  Market  Study  Background 

This  Market  Study  focuses  (m  die  need  for  a  concurrent  design  environment  for 
MCM  software  tools.  We  identify  the  features  that  could  be  supported  based  on 
our  interpretation  of  the  requirements  and  opinions  of  a  select  group  of  systems 
electronics  specialists  employed  by  some  of  die  leading  electronics  systems 
conqianies  in  die  United  States. 

The  infonnation  collected  during  the  course  of  this  program  includes  both  con¬ 
current  engineering  environment  issues  as  well  as  the  functicmality  of  individual 
MCM  design  tools.  Our  focus  is  cm  die  concurrent  engineering  environment 
issues;  dierefore,  we  do  not  discuss  development  of  individual  MCM  design 
tools  in  our  conclusions.  We  ask  the  reader  to  not  make  an  inference  from  diis 
enqihasis  the  importance  of  design  tools  versus  design  environments  ~  rather, 
the  reader  should  assume  that  end-users  have  needs  in  both  areas. 

The  data  presented  in  this  market  study  was  derived  from  a  variety  of  industry 
sources,  including  end-users  of  concurrent  engineering  technology,  suppliers  of 
database  technology,  MCM  manufacturers,  and  industry  consultants.  Prospec¬ 
tive  customers  invcdved  in  either  die  design  or  die  manufacture  of  MCMs  were 
identified  by  Harris  EDA,  MCC,  and  Harris  GASD.  This  select  list  was  contacted 
dirough  telemarketing  services  and  personal  interviews.  The  information  gath¬ 
ered  from  surveys  and  interviews  was  combined  with  available  published 
information  from  trade  journals,  consultant's  presentations,  vendor  literature, 
industry  reports,  and  other  market  studies. 

Subsequendy,  die  conclusions  reached  by  this  focused  Market  Study  were  then 
carefully  reviewed,  discussed  and  debat^  by  the  Market  Study  Program  Team, 
resulting  in  the  generaticm  of  this  dociunent. 

Program  Team 

The  Program  Team  included  representatives  from  several  companies.  Tony 
Mazzullo,  Vice  President  of  Business  Development  at  Harris  EDA  has  acted  as 
the  overall  Program  Manager  and  Team  Leader. 
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The  Program  Team  is  comprised  of  fdlowing  individuals: 

Harris  EDA 

Dr.  Tom  Benfey,  Marketing  Communications  Manager 

Tony  Casdano,  Manager,  Software  Engmeering 

Jacqueline  FUmagan,  Manager,  Corporate  Relaticms 

Chuck  Gannon,  Senior  Software  Engineer 

Dennis  George,  CAD  Product  Maiuiger 

Khnberly  Hayton,  Marketing  Specialist 

Robert  IngoM,  Product  Markedly  Specialist 

Vess  Johnson,  Director  CAD  Development 

Tony  Mazzullo,  Vice  President  of  Business  Developmen 

Kathryn  M.  Wise,  Supervisor,  Technical  Publications 

Harris  Corporation  Engineering  Productivity  Group 
Bruce  Kraemer,  Manager  Engineering  Productivity 

Harris  Corporation  GASD 
Don  Hege,  Lead  Engineer 
Tom  Young,  Associate  Principal  Engineer 
Lou  Paradiso,  Sr.  Principal  Engineer 

Harris  Corporation  Marketing  Services 

Terry  Beard,  Senior  Manager,  Marketing  Support 

Glenn  Pertersen,  Senior  Manager,  Marketing  Support  Admin 

Microelectronics  and  Computer  Technology  Corporation  (MCC) 

Hector  Moreno,  Program  Manager 
Shaune  Stark,  Member  of  Technical  Staff 

STEP  Tools,  Inc. 

Dr.  Martin  Hardwick,  President 

The  following  individuals  also  provided  sigruficant  contributions  to  the  devel 
opment  of  Bus  Market  Study. 

Bill  Bicknell,  General  Electric  Corporate  R  &  D 

Ray  Pillion,  General  Electric  Corporate  R  &  D 

Charles  Incavellia,  General  Electric  Corporate  R  &  D 

Tim  Ryan,  IBM  Microelectronics 

Mark  Eskew,  Texas  Instruments 

Tom  Laliberty,  Raytheon  Company 

Linda  Lapoint,  Raytiieon  Company 
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Section  3  —  Description  of  Technology 

In  recent  years  users  oi  con^uter-aided  design  systems  want  their  application 
programs  (tools)  capable  of  exchanging  iniormation  as  seamless  as  possible.  The 
teasoiu  are  obvious:  less  of  dieir  dieir  time,  less  of  dieir  effort,  and  more 
economical  use  of  their  software/hardware  investment.  In  parallel,  the  Federal 
govenunent  launched  the  DICE  •  DARPA  (now  ARP  A)  Initiative  on  Concurrent 
Engineeting  -  program  five  years  ago  to  support  die  develc^ment  of  tools  and 
methodolc^es  that  improve  productivity  in  design  and  manufacture  dirough 
the  concurrent  activities  in  diose  areas. 

Multi-Chip  Module  (MCM)  design  could  benefit  a  great  deal  from  enabling 
conciurent  technology  for  many  reasons: 

1)  MCMs  represent  the  cutting  edge  of  system  technology  at  diis  time; 
therefore,  design  and  manufacturing  processes  are  relatively  new  and  can 
be  changed  easier  than  processes  in  place  for  older  technologies. 

2)  The  complexity  of  the  design  tasks  is  so  great  that  several  inter-disciplinary 
teams  are  necessarily  involved. 

3)  As  a  result,  many  distinct  con^uter-aided  tools  must  be  used  to  complete 
the  design  of  one  MCM. 

4)  In  the  most  part,  the  tools  do  not  work  togedier  well  since  they  liave  been 
developed  by  different  software  sources,  and  lack  a  common  software 
envirorunent. 

Because  of  the  tools  have  not  worted  togedier  well,  people  have  had  to  adopt  a 
serial  MCM  design  methodology.  With  this  process,  ea^  set  of  experts  accepts 
the  design  from  the  previous  team,  and  tries  to  make  die  MCM  comply  with  the 
product  specifications  necessary  for  its  particular  area.  Because  die  iriformation 
flow  is  uni-directional,  a  problem  in  die  design  results  in  it  being  "sent  back"  to  a 
prior  stage  in  order  to  be  fixed.  This  back-trackings  usually  negates  most  of  the 
work  done  at  intermediate  sta^.  Worse  stiU,  the  work  that  one  group  does  to 
achieve  its  own  goals  often  collides  and  interferes  with  die  needs  of  a  different 
group.  For  exan^le,  in  order  to  achieve  full  testability  with  a  given  test 
approach,  additic^  circuitry  may  be  needed.  However,  additional  circuitry 
may  ccmtradict  the  needs  for  spe^  and  perfonnance,  or  the  requirements  for 
size  and  weight  important  to  other  design  teams. 

With  the  conciurent  design  engineering  approach,  information  flows  between 
users  of  distinct  design  tools  in  a  multi-sectional  way.  Any  changes  and 
solutions  diat  a  group  offers  can  be  quickly  evaluated  by  others  and  problems 
can  be  identified  early  and  solved  quickly.  Thus  the  serial  design  approach  is 
transformed  into  a  paralld  (me,  and  tiie  design  process  becomes  centn^  on  tiie 
data  (information)  itself,  and  not  controlled  by  the  available  tools. 

Witii  tiiis  important  point  in  mind,  a  research  group  at  tiie  Rensselaer 
Polytechnic  Institute  (RI^,  offered  a  proposal  to  DICE  to  develop  an  engineering 
data  management  S3rstem,  called  ROSE  (Rensselaer  Object  Storage  Environment). 
The  prop<)^  has  been  funded  through  several  phases  of  DICE,  and  ROSE 
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continues  to  evolve  to  this  date.  ROSE  is  now  conunerdally  supported  by  STEP 
Tools,  bic. 

Along  with  toe  problems  of  serial  information  flow,  engineering  design  methods 
must  sdve  engineering  data  management  problems  that  are  much  more 
complicated  than  toe  typical  data  management  problems  found  in  business.  In 
business,  the  data  is  usually  well  defined  in  advance  of  its  creation.  For 
example,  banks  deal  with  depositors  and  borrowers.  A  depositor's  or  borrower  s 
business  information  is  accessed  through  a  tuune,  address,  social  security 
number,  and  account  number.  The  business  data  records  contain  balances, 
payments,  loans,  dates,  and  interest.  All  customers,  regardless  of  the  amount  of 
rrumey  toey  possess,  require  the  same  number  of  records  for  data  storage  and 
management.  This  data  can  be  handled  with  relatiorud  database  technology, 
normally  fixed>lengto  records  organized  for  presentation  in  tabular  form. 

By  contrast,  engineering  design  produces  data  in  seerxungly  random  form  and 
size.  The  layout  of  an  electrical  cormection  path,  for  example,  can  have  any 
number  of  comers  or  bends  in  its  physical  implementation.  An  actual  picture  of 
toe  electrical  connection  is  a  much  more  use^  representation  of  the  data.  Thus, 
engineering  data  is  more  efficiently  and  faithfully  represented  by  software 
objects,  which  are  encapsulatiorts  of  data  and  software  like  the  graphics  software 
that  makes  toe  drawing  of  the  path  appear  on  toe  screen,  ratl^  than  as  sets  of 
fixed  Imgto  records. 

ROSE  serves  as  a  vast  software  library  of  object  maiupulation  and  storage  which 
can  be  used  by  the  engineering  applications.  This  object-oriented  software  can 
be  reused  in  a  straightforward  maimer,  eliminating  duplication  efforts  and 
debugging  problems.  For  example,  the  graphics  display  software  that  an  object 
uses  may  have  been  written  in  advance  for  a  more  generic  type  of  object.  In  toe 
same  manner,  data  management  software  for  a  particular  piece  of  data  can  be 
inherited  from  software  written  previously. 

ROSE  also  helps  to  expedite  the  flow  of  information  between  customers  and 
suppliers,  designers  and  users  of  design  inforanation,  while  complying  with 
international  standards.  The  ISO  and  PDES/STEP  organizations  as  well  as  the 
work  of  the  EDIF  committees  and  CFI  demonstrate  toe  great  interest  in  sharing 
data.  ROSE  is  compliant  with  toe  STEP  norms  as  the  structured  objects  it 
c^Terates  cm  are  defined  through  toe  BO/PDES/STEP  EXPRESS  language  for 
information  modeling. 

CHOICE  Technology  Overview 

In  1989,  MCC  pr<^K)sed  to  DICE  to  validate  the  ROSE  technology  through  toe 
creation  of  a  concurrent  MCM  design  environment.  Implementation  of  the 
design  environment  required  two  phases: 

1.  Define  an  EXPRESS  information  model  for  MCM  physical  design  data  and 
validate  it  through  ROSE  and  toe  bidirectional  linking  of  several 
commercially  available  CAD  tools. 
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In  addition,  the  validation  included  the  concurrent  design  of  a  commercial 
MCM. 


This  first  phase  was  funded  and  resulted  in  the  CHOICE  technology  which 
is  the  sub^  of  this  market  study. 

2.  Expand  die  omcurrent  design  environment  to  include  and  validate  other 
design  aspects  such  as  logical,  electrical,  mechanical,  thermal  modeling  and 
simulation  as  well  as  design-for-test. 

This  second  phase,  aldiough  approved  in  principle,  has  not  yet  received 
funding. 

Description  of  the  CHOICE  Technology 

There  are  two  basic  types  of  entities  needed  to  represent  MCM  physical 
design  data; 

•  Geometric  information  entities. 

•  Connectivity  information  entities. 

Our  method  first  examined  what  data  types  were  required  by  a  system 
which  is  predominantly  used  for  layout  since  we  expected  Ihese  types 
were  common  among  all  the  systems  to  be  integrated.  Then  we 
determined  which  types  were  necessary  to  complete  the  picture  for 
systems  with  connectivity  intelligence.  Each  of  these  identified  types  was 
defined  as  an  abstract  entity.  We  expressed  the  information  content 
through  the  interrelationship  among  aU  the  entities.  We  codified  this 
interrelationship,  known  as  the  schema,  with  the  EXPRESS  language  and 
included  the  following  geometric  entities: 

•  Cells 

•  Mosaics  (Arrays) 

•  Cell  Instances 

•  Geometric  Primitives 

-  Paths 

-  Rectangles 

-  Polygons 

-  Lines 

-  Points 

The  connectivity  entities  were: 

-  Element-pin  pairs  (riPin) 

-  Nets 


ARPA  Market  Study  —  Technology 


Section  3  •  Page  3 


EXPRESS  Model  ImplemenUtioii 

Figure  3.1  shows  four  ph3rsical  design  CAD  systems  and  two  ROSE 
ixnplemmtations  for  two  different  i^onnation  models:  the  CHOICE 
S^^TEM  introduced  in  the  previous  section  and  one  diat  implements  the 
Initial  Graphics  Exchange  Standard  (IGES).  IGES  is  a  very  general,  three- 
dimensicMial  standard  that  represents  graphical  informaticm  and  was  quite 
cumbersome  for  our  purposes.  However,  we  found  it  necessary  to  work 
witti  IGES  because  systems  such  as  Allegro  6.1  (PCB-oriented  tools)  often 
accept  IGES  representation  of  graphical  data  as  input,  without  providing 
many  other  acceptable  means  to  r^bly  input  data  brom  external  sources, 
and  do  not  provide  a  procedural  language  to  read  or  write  to  its  internal 
data.  )Allegro  6.1  is  also  capable  of  writing  out  its  layout  design  data  in 
IGES  form.) 


Figure  3.1.  Architecture  cfthe  CHOICE  system. 


AutoCAD  implements  a  more  direct  link  between  the  MCC  information 
model  and  its  own  internal  format  by  using  a  direct  C  procedural  access  to 
its  database;  fois  provides  a  direct  link  for  data  exchange.  AutoCAD 
reads  from  and  writes  to  ROSE  data  directly,  without  an  intermediate 
format,  simply  by  loading  die  C  language  interface  that  MCC  has  written 
usii^  AutoCAD's  "AutoCAD  Development  System"  (ADS)  tool. 

Die  two  information  models,  MCC’s  and  IGES,  were  written  in  the 
EXPRESS  language.  Software  toob  from  STEP  Tools,  Inc.  were  then  used 
to  cmnpile  di^  models  into  C-t")-  classes.  ROSE  also  provides  methods  to 
create  die  flans  instances,  to  relate  them  according  to  the  schema  and  to 
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manage  them.  In  addition,  we  mapped  the  ROSE  objects  created  under 
one  model  to  ot^ects  created  under  the  other  through  C-n-f  ROSE  code, 
thereby  integrating  Allegro  into  CHOICE. 

The  link  between  Edge/Opus  and  ROSE  is  achieved  through  an 
intermediate  text  form.  Data  goes  in  and  out  of  Edge/Opus  via  software 
written  in  Cadence's  SKILL  language,  which  allows  read/write  access  to 
Edge/Ppus'  internal  data  structures.  The  link  to  ROSE  was  completed 
dvough  a  parser  written  in  C-h-,  which  reads  die  intermediate  form  and 
creates  the  (C-t-t-)  objects  that  implement  the  EXPRESS  layout  information 
model.  In  the  qrposite  direction,  C-h-  software  navigates  through  the 
ROSE  objects  and  creates  die  intermediate  form  description,  which  is  then 
read  by  die  Cadence  SKILL  code. 

The  FINESSE  MCM  system  was  linked  to  the  ROSE  database  through  an 
intermediate  text  file  form  called  a  dfile,  a  standard  textual  database 
description  form  that  FINESSE  MCM  supports  and  can  be  read  back  to 
recreate  the  FINESSE  MCM  database  through  that  tool's  command  stream. 
Our  original  intention  was  to  integrate  FIN^SE  MCM  in  a  direct  fashion, 
without  an  intermediate  text  form,  since  Harris  EDA  owns  the  source  code 
for  FINESSE  MCM.  However,  Harris  EDA  determined  that  such  a  route 
would  take  more  time  and  resources  than  those  allowed  by  our  project. 
The  link  through  the  dfile  was  developed  very  much  like  the  Cadence 
Edge/Opus  link. 

Operation  of  the  Concurrent  Engineering  Layout  System 
Figure  3.2  illustrates  the  operation  of  the  system. 


Data  In  appropriate  form: 
native  or  text 


Figure  3.2.  CHOICE  system  operation. 
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The  basic  object  that  is  managed  by  ROSE  is  the  cell,  and  any  transaction 
between  a  user  and  die  system  involves  at  least  the  transfer  oi  a  complete 
Cell  entity.  That  implies  duit  layout  designers  must  OTganize  and  structure 
data,  limitu^  the  size  of  individual  cells  so  transfer  of  data  relatively 
simple.  Go^  data  structuring,  alwaysa  good  practice  regardless  of 
concurrent  engineering  requirements,  is  essential  with  ROSE  since  all 
users  of  the  system  must  be  informed  of  every  change.  ROSE  in  and  of 
itself  does  not  require  cells  as  basic  exdiange  entities.  However,  from  a 
practical  point  of  view,  definir^  die  exchange  granularity  at  a  lower  level, 
could  produce  a  prohibitively  large  amount  of  network  traffic  due  to  die 
vast  number  of  minute  changes  diat  the  design  team  may  make.  This 
would  trigger  corresponding  ROSE  database  searches  for  die  objects  being 
modified,  added  cx  deleted.  Since  die  natural  unit  of  work  in  layout  is  the 
cell,  it  is  equally  natural  to  use  it  as  the  transaction  unit  The  ROSE  data 
dien  is  updated  only  when  die  designer  finishes  a  sizable  amount  of  work. 
This  approach  alw  eliminates  the  need  for  database  searches  for 
individual  objects,  as  the  whole  cell  gets  updated  every  time.  However, 
the  cells  should  remain  small  so  updates  are  completed  more  quickly. 

Every  cell  entity  is  stored  as  an  individual  ROSE  design  on  one  dedicated 
workstation  with  efficient  disk  access.  The  user  invok^  a  custom  server  to 
update  die  other  workstations  in  die  network 

When  a  designer  receives  an  update,  die  system  automatically  backs  up 
the  designer's  current  working  design.  This  enables  the  team  to  assessthe 
update  and  either  accept  or  reject  die  change.  The  team  works  togedier  to 
determine  whether  the  update  is  immediately  acceptable,  whether  it 
should  be  modified,  or  whedier  the  current  working  design  needs  to  be 
modified  to  support  die  update.  The  automatic  back-ups  enable  the  team 
to  return  the  design  to  previous  stages,  if  that  is  the  concensus. 

Saving  and  Updating  Infomution 

After  completing  work  on  a  cell,  die  designer  saves  it  to  the  local  CAD 
sjrstem  database  and  also  invokes  the  ROSE  server  to  receive  the  data  and 
create  the  ROSE  description  of  the  cell.  Because  the  server  uses  a  different 
workstation,  the  designer  experiences  a  minimal  downtime  when  saving 
the  cell  to  die  ROSE  environment  Since  the  cell  updates  are  not  occurring 
frequendy,  die  network  traffic  is  minimized.  Once  the  cell  has  been  stored 
as  a  ROSE  design,  the  ROSE  server  translates  it  to  all  the  other  formats 
necessary  to  update  the  other  CAD  systems. 

Special  Considerations 

Internal  database  of  certain  CAD  systems  use  a  minimum  of  hierarchy. 
Essentially,  diese  s3rstems,  which  have  evolved  from  Printed-Circuit  Board 
layout  applications  to  the  MCM  domain  keep  "packages,"  "pad  stacks," 
and  "boards"  as  basic  entities.  A  board  describe  the  MCM  itself  and 
contains  packages  and  interconnect.  The  packages  are  built  out  of  pad 
stacks  and  odier  geometric  and  electrical  information.  These  systems. 
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usually  very  useful  to  cnnplete  tihe  routing  porticm  of  the  MCM  layout 
task,  but  diey  are  not  especially  suited  to  hatuUe  large  amounts  of  data, 
particularly  certain  MCM  technologies  which  customize  the  MCM 
substrate  starting  from  a  generic,  prefabricated  part  which  is  customized 
in  die  last  stage  of  manufacturing.  Such  parts  are  mass  produced  ahead  of 
time  and  contain  a  great  deal  of  intercoimect  which  will  not  used  by  the 
personalization  step.  (Usually  only  abut  60  percent  of  available 
interconnect  density  are  actually  used  for  those  substrates).  In  such  cases, 
the  part  slunild  be  described  con^iletely  in  in  a  hierarchical  CAD  system. 

If  a  nonrhierarchical  CAD  system  is  used  for  die  routing  in  a  concurrent 
engineering  approach,  only  pass  die  placement  information  and  the 
ne^t,  and  d^  to  store  ^  interconnect  generated  back  into  ROSE  . 
Alternatively,  if  designers  can  wcvk  effectively  in  the  non-hierarchical 
system  widi  all  the  MCM  data,  they  should  not  store  back  into  ROSE  the 
full  design  after  routing  since  diat  would  create  a  flat  and  large  cell 
containii^  all  die  layout  data.  In  any  case  only  die  result  of  die 
interconnect  (routing)  step  should  be  stored  in  a  new  cell,  which  will  be 
shared  by  all  the  concurrent  engineering  environment  designers. 
Furthermore,  if  designers  can  complete  interconnection  using  a  sequence 
of  smaller  tasks,  diey  should  store  the  results  of  each  of  those  tasks  as 
independent  cells. 

In  other  cases,  all  members  of  die  design  team  might  collaborate  in 
defining  the  basic  packages  and  their  placement,  and  then  they  would 
submit  the  intercormect  task  to  the  non*hierarchical  system  (or  systems  ) 
as  the  last  step  of  the  layout  design. 

UNIX  Server 

To  integrate  the  users  of  the  concurrent  engineering  environment,  we 
implemented  a  mechanism  by  which  the  UNIX  system  will  automatically 
update  and  distribute  the  changes  to  the  ROSE  database.  Essentially,  all 
users  have  their  own  usual  working  environment,  but  in  addition  have 
two  extra  directories:  incoming  and  outgoing.  To  update  the  ROSE 
database,  the  user  saves  the  work  to  the  outgoing  directory.  Once  the 
server  is  invcdced,  the  directory  is  "moved”  or  renamed  to  a  predetermined 
location,  pericxiically  inspected  by  the  UNIX  server.  If  the  server  finds 
data  fliere,  it  mates  a  backup  copy  and  performs  all  necessary 
manipulations  to  change  the  new  data  into  the  CHOICE  form  and,  from 
there,  translates  it  to  aU  other  integrated  systems.  Since  the  server  runs 
independently,  the  designer  is  not  affected  by  die  server's  activity. 
Typically  the  server  is  a  SPARCStation  10  with  50+  Megabytes  of  memory 
a^  enou^  storage  space  depending  cm  the  size  of  the  database  and 
number  of  designs  beii^  iruuiaged. 

Once  the  translaticms  are  complete,  the  server  copies  the  ROSE  database  to 
adirectory  and  creates  a  backup  copy  of  the  previous  data.  Because  all 
users  and  their  CAD  system  '"pes  are  register^  in  a  special  file  the  server 
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reads,  the  server  distributes  a  copy  of  the  translation  in  all  users'  iiKonung 
directory.  Users  inspect  this  directory  and  evaluate  die  change. 

If  the  changes  are  acceptable,  users  update  tlwir  designs,  move  die  file  in 
die  incoming  directory  to  another  location,  and  prepare  to  receive  any 
other  updates  in  die  incoming  directory.  If  users  don't  accept  or  agree 
widi  the  changes,  diey  must  communicate  with  odier  design  team 
members  and  determine  how  to  proceed.  Backup  copies  of  die  design 
exist  and  can  be  reinstated.  Or  tte  designers  critical  of  die  change  may 
have  to  alter  dieir  own  data  and  submit  it  again  to  die  server. 

The  current  server  mechanism  is  an  interim  solution.  Ultimately  ROSE 
needs  bodi  a  database  versioi  control  and  a  design  checking/locking 
medianism.  Once  diese  features  are  available,  the  server  can  invoke  diem 
on  bdialf  of  the  user  who  is  submitting  the  change  or  requesting  a  ^ledfic 
piece  of  information  or  version  of  die  data. 

DDR2  Parts  and  Nedist 

DDR2  (Digital  Drop  Receiver,  Version  2),  die  module  we  designed 
concurrendy  with  the  CHOICE  s)rstem,  is  owned  by  Harris  Corporation. 
The  parts  were  designed  using  FINESSE  MCM  and  die  nedist  had  been 
ente^  into  the  FINESSE  MCM  system.  From  diere,  diat  information  was 
made  available  to  the  odier  CAD  systems  dirough  die  ROSE  database  and 
the  CHOICE  s)rstem. 

Installing  and  Supporting  die  System  at  Harris  Corporation 

In  October,  1992,  a  team  of  foiur  software  developers,  three  from  MCC 
and  one  from  Harris  EDA,  installed  die  system  at  Harris  Corporation  in 
Melbourne,  Horida.  There  the  team  translated  the  DDR2  placement  and 
nedist  from  Harris  EDA's  FINESSE  MCM  to  the  Allegro  6.1  system,  since 
diese  two  CAD  systems  were  the  relevant  design  systems  at  Harris 
Corporation.  After  the  demonstraticm,  Harris  Corporation  designers  used 
the  S3rstem  to  pass  information  between  FINESSE  MCM  and  Allegro  for 
other  MCM  applications. 

Concurrent  Engineering  Design  Experience  at  MCC 

In  (vder  to  validate  the  concurrent  engineering  design  environment 
provided  by  the  CHOICE  system,  MCC  completed  a  design  of  the  DDR2 
Harris  module.  MCC  took  the  parts  description,  placement  and  nedist 
from  the  database  that  Harris  delivered  in  FIN^SE  MCM  form.  The 
ROSE  database  was  created  and  the  Cadence  Edge/Opus  system  read  it 
in.  Die  footprints  of  the  chips  and  the  module  I/O  were  then  modified  to 
allow  for  automatic  redundant  routing  by  judicious  modification  of  the 
padstack  definitions.  Die  placement  data  and  die  nedist  were  dien  read  by 
the  Allegro  S3rstem  and  routed.  The  Allegro  system  also  created  the 
power  and  ground  plane  data.  Die  routed  Allegro  database  was  then  sent 
back  to  the  ROSE  database  and  read  in  by  die  Cadence  Edge/Opus 
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^stem,  which  was  then  used  to  replicate  the  signal  aiul  power/ground 
layers. 

The  via  entities  vtete  also  redefined  in  die  Cadence  Edge/Opus  system  to 
have  geometric  elements  in  die  normal  as  well  as  die  redundant  routing 
layers.  The  replicadon  stqp  is  trivial  in  die  Edge/Opus  system  but  not  in 
die  Allegro  or  FINESSE  MCM  systems. 

MCC  also  wrote  ^ledal  verificati<m  software  aids  to  take  the  nedist,  chip 
placement,  and  nedist  information  residing  in  die  ROSE  database  and 
dien  generate  a  text  file  whose  records  list  the  net  names  followed  by  die 
absolute  x-  and  y-Cartesian  co(»dinate  location  of  die  chip  and  module 
I/O  pins  corresponding  to  the  listed  net  name.  Such  a  text  Me  is  read  into 
die  Cadence  Eidge/Opus  database  using  die  SKILL  language  and  die 
cotie^KViding  net  names  iviitten  as  labels  into  die  native  Cadence 
database  in  a  chosen  layer  at  die  x>  ,y>location  recorded  in  die  text  file. 
The  software  verifying  Ed^/Opus  connectivity  depends  on  this 
annotation.  Through  simple  textual  editing  operations  on  the  text  file,  it  is 
possible  to  derive  a  corresponding  text  file  for  the  redundant  net  names, 
which  are  dien  also  ir^ut  as  labels  into  the  Edge/Opus  database  (in  a 
different  layer  tiian  dut  used  for  die  normal  net  names).  Through 
straightforward  graphical  (^lerations,  the  labels  are  moved  to  desired 
locaticms  cm  die  ^undant  pads  and  then  moved  to  the  same  layer  as  the 
normal  net  name  labels.  At  diat  point  die  Edge/Opus  database  is  ready 
for  full  connectivity  and  design  rule  verification. 

This  exceedingly  powerful  design  mediod  allows  us  to  perform  operaticms 
that  nonnally  are  not  allowed  in  connectivity-based  systems,  but  which 
are  very  desirable.  Those  "forbidden”  operations,  such  as  adding  layers, 
replicating  design  data,  adding  ccmnections  not  listed  in  die  original 
nedist,  are  practically  trivial  in  the  Edge/Opus  system.  Through  the  tool 
integration  and  verification  process,  we  are  assur^  of  the  integrity  of  the 
design. 

In  our  experiment,  we  obtained  a  fully  verified  database  suitable  for 
manufacturing  in  four  designer-days.  The  design  rules  used  were  those  of 
MCC's  QTAI  thin  film  MCM  interconnect  process.  In  comparison,  the 
same  d^gn  when  processed  through  tiie  standard  non-concurrent 
approach  tidces  one  designer-mcmdi  of  efiort.  These  factors  contributed  to 
die  time  savings: 

1)  The  ability  to  use  and  re-use  previously  designed  data  elements.  In 
our  case,  we  used  die  chip  and  module  I/O  footprint  definitions 
contained  in  die  initial  FIN^^  MCM  database.  The  reuse  of  data 
eliminates  transcription  errors  and  saves  a  great  deal  of  design  time. 

2)  The  ability  to  use  die  best  features  of  each  and  every  integrated  tool. 
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Standards  considerations 

Standards  organizations  have  special  interest  in  setting  up  tools,  application 
protocols,  infonnation  modeb  and  guidelines  to  facilitate  the  transfer  of 
information  among  diffdent  parties.  The  DICE  program  from  which  the 
CHOICE  environment  has  evolved  is  compliant  with  die  PDES/STEP 
requirement  to  have  die  data  conform  to  an  EXPRESS  information  model.  After 
die  first  phase  of  the  project  has  been  completed,  this  study  appears  to  indicate 
dut  diere  is  renewed  interest  in  evolving  die  environment  to  encompass  a 
promising  emerging  standard  information  model  for  PCB  data  which  is  being 
devel(q>ed  by  tte  EDIF  PCB  ounmittee.  In  addition,  die  ongoing  coordiiuited 
efforts  between  die  PDES/STEP  AP210  working  group,  the  EDIF  community 
and  die  CFI  promote  integration  and  furdier  research.  The  ARPA-^>onsored 
ASEM  CAD  Alliance  project  at  MCC  is  actively  working  widi  all  these  groups  in 
extending  the  PCB  information  model  to  die  MCM  realm.  As  die  CHOICE 
techndogy  moves  into  its  prqected  commercialization  stage,  it  will  continue  to 
evolve  and  will  adopt  die  chosen  informatimi  model  standard. 

Rensellaer  Object  Storage  Environment  (ROSE) 

ROSE  is  a  system  diat  allows  applications  written  in  object-oriented  program¬ 
ming  languages  to  interact  direcdy  with  databases  that  have  been  defizied  using 
die  EXPRESS  modeling  language.  Different  ROSE  systems  are  available  that 
support  different  object-oriented  programming  languages.  For  example, 
ROSE-m*  is  a  class  library  for  C++  applications  [Hardwick  92]. 

In  order  to  evaluate  die  ROSE  database  system  we  must  look  at  several  features 
of  die  system  including: 

•  Logical  Database  Architecture 

•  Data  Definition  Language  (DDL) 

•  Toob  Built  On  the  Database  System 

•  Work  With  ROSE 
Logical  Database  Architecture 

ROSE  b  built  using  an  object-oriented  database  architectiu’e.  Thb  architecture  b 
well  suited  for  mt^eling  design  data  and  b  actually  capable  of  capturing  more 
semantics  in  the  database  than  other  database  modeb.  In  order  to  understand 
what  die  object-oriented  architecture  provides  we  should  consider  how  thb 
conqiates  to  die  more  common  relation^  architecture. 

Rdational  Database  Architecture 

Rebtional  databases  arrange  data  in  a  collection  of  relations,  each  of  which  is 
represented  in  a  tabular  form  that  b  easily  understood  [Date  86).  The  rows  of  a 
ration  or  a  table  are  called  tuples,  while  columns  are  called  attributes.  In  the 
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rdational  model,  entities  and  relationships  between  entities  are  both  represented 
in  die  same  way  -  as  a  relaticm. 

Relational  databases  are  extremely  good  for  performing  ad  hoc  queries.  For 
example,  consider  die  part  table  in  Figure  3.3.  In  die  PARTS  table  queries  listing 
all  die  sources  fot  particular  package  type  seems  quite  natural.  The  database 
structure  lends  its^  well  to  generating  queries  diat  perform  directed  searches 
over  well  defined  combinations  of  relations.  This  capability  may  indeed  make 
rdational  databases  very  well  suited  fot  die  maintenance  of  library  data. 


Conqiany:. 


Part  Number 

Manufocturer 

Package 

Material 

7400-1 

JKSemi 

14-DIP 

Plastic 

7400-2 

JKSemi 

14-DIP 

Ceramic 

7400-3 

]KSemi 

20-FP 

Ceramic 

7400-4 

^Semi 

14-DIP 

Plastic 

7400-5 

SJSemi 

20-FP 

Ceramic 

Figure  3  PARTS  Table 

hi  die  relatitmal  model  there  is  no  method  for  storing  explicit  links  between  the 
data  items.  As  discussed  earlier  the  relational  architecture  makes  use  of  the 
relation  as  its  prindple  data  structure.  Hence,  while  performing  ad  hoc  queries 
may  be  quite  intuitive,  database  traversals  can  be  quite  complex.  Although  the 
relational  model  can  handle  queries  centered  around  focused  entity  types  (e.g., 
what  is  the  resistance  value  for  the  part  with  part  number  R12345),  queries  con¬ 
cerning  entities  related  to  odier  entities  could  present  a  problem  (e.g.,  which  nets 
are  die  pins  on  coiiq>onent  U1  crmnected  to,  what  coiiqionent  is  above 
component  Ul). 

However,  diis  lack  of  explicit  links  between  the  items  in  multiple  relations  is  not 
always  a  weakness.  The  relational  database  architecture  also  provides  a  hi^ 
degree  (d  data  independence.  The  data  in  the  database  is  not  restricted  to 
particular  location  since  there  are  no  predefined  access  padis  or  explicit  links. 
Less  enqihasis  is  placed  on  die  actual  locaticm  of  data  within  the  database  than 
diat  found  in  odier  database  systems  dierefore  fewer  problems  may  be 
encountered  during  database  restructuring. 

Another  important  aspect  of  relational  database  architectures  is  the  maturity  of 
die  technology.  Maturity  of  a  technology  can  bring  with  it  some  significant 
advantages,  for  exao^le: 
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•  Relational  database  systems  have  been  in  use  for  a  Icmg  period  of  time  and 
there  have  been  a  large  number  of  tools  being  built  on  diem  in  many  diverse 
problon  domains. 

•  Relational  database  management  systems  are  quite  robust  in  areas  such  as 
concunent  processing,  transaction  processing  and  security. 

•  Standard  query  languages  have  been  defined  and  agreed  up<m.  Moving 
from  one  rational  database  8)rstems  to  another  may  pose  a  minimal  inqiact. 

•  Interoperability  in  relational  database  environments  is  nearly  a  reality.  This 
is  not  meant  to  imply  apptication  interoperability.  Rafr^,  data  that  is 
defined  in  one  relational  database  system  can  be  accessed  frcnn  another 
relational  database  system  of  a  different  type. 

Object-Orie^ited  Database  Architecture 

Object-oriented  databases  ate  based  on  the  notion  of  objects  and  the  relation¬ 
ships  between  objects.  This  architecture  is  a  move  toward  more  of  a  traversal 
oriented  database  architecture  where  less  emphasis  is  placed  on  the  ad  hoc  query 
structure.  Object-oriented  databases  attempt  to  capture  more  of  tiie  semantics  of 
tile  data  being  modeled  as  well  as  semantics  about  tiie  entity  interactions,  unlike 
tile  CODASYL  network  databases  which  are  also  traversal  oriented 

Rdational  database  systems  can  be  viewed  as  modeling  data  in  a  flat  tabular 
view  with  multiple  entry  points  for  data  retrieval.  While  object-oriented 
database  systems  on  the  otiia  hand  can  be  viewed  as  modeling  large  conqilex 
networks  of  interconnecting  objects  and  entities  with  fewer  well  defined  entry 
points  for  data  retrieval.  Where  tiie  relational  database  is  good  for  tiie  library 
definitions  of  entities,  envisic^ied  as  lookup  tables,  the  object-oriented  database 
is  well  suited  for  design  databases  with  many  interconnected  design  entities  or 
olqects  (Figures  3.4  and  3.5). 


Parts  Pins  Functions  Shapes 


Figure  3.4  Objects 
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FigunSS.  Objects  and  Explicit  Unks 


The  maintenance  of  explicit  links  between  entities  in  ttie  database  allows  the 
application  to  efficiently  traverse  du ough  d\e  database.  These  explicit  links  also 
r^uces  the  amount  of  data  independence.  Now  the  database  structure  is  much 
more  stressed  and  reUed  upon  that  may  make  structural  redesigns  more  difficult. 

One  area  of  concern  for  object-oriented  databases  is  the  maturity  of  the 
technology.  There  are  few  staiidards  currently  available  that  allow  for  data  to  be 
transfenred  between  different  systems.  Also,  in  many  cases  moving  from  one 
object-oriented  database  system  to  anotiter  requires  considerable  efiort  in 
moving  the  data  and  in  learning  die  new  system. 

However,  diere  are  standard  committees  that  have  been  active  now  for  some 
time  addressing  these  concerns.  This  concern  is  continuing  to  fade  as  it 
ultimately  did  with  the  relational  database  technology. 

To  say  that  one  database  architecture  in  all  cases  is  superior  to  anodier  is  quite 
iiuippropiiate.  The  relational  database  architecture  is  positioned  well  and  it  is 
clearly  die  tool  of  choice  when  die  application  domain  is  appropriate.  The 
object-<niented  database  architecture,  similarly,  has  strengths  that  position  it 
w^  for  die  appropriate  application  domain.  For  the  maintenance,  interchange 
and  manipulation  of  design  data  the  object-oriented  database  architecture  is 
cunendy  the  architecture  of  choice. 

Data  D^inition  Language  (DDL)  and  EXPRESS 

The  Data  Definition  Language  is  the  language  used  to  define  the  logical 
structure  of  a  database  [Loomis  87].  This  is  sometimes  referred  to  as  the  ’’schema 
d^itum  language". 

Most  database  management  systems  in  use  today,  including  most  relational 
database  management  systems,  use  proprietary  DDL's.  There  are  efforts 
underway  by  commercial  relational  database  vendors  to  standardize  the  DDL's 
in  die  database  community;  however,  this  work  is  not  complete.  Hence,  the 
migration  from  one  database  system  to  anodier  can  be  quite  ch^enging. 
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One  of  die  most  important  aspects  to  d\e  ROSE  database  is  its  use  of  EXPRESS 
for  its  DDL.  EXPRESS  is  an  extronely  powerful  modeling  language  for 
engineering  design  data.  EXPRESS  describe  data  structures  as  well  as  the 
omstraints  that  must  be  met  by  instance  of  diose  structures.  The  EXPRESS 
language  is  object  oriente  and  definitions  can  inherit  from  one  another. 

The  EXPRESS  language  is  included  in  d\e  ISO  10303  PDK/Sl'EP  Standard  (ISO 
10303>11).  Part  21  of  the  standard  describes  die  STEP  file  format.  Part  22  of  the 
standard,  die  STEP  Data  Access  Interface  (SDAI),  defines  Application 
Programmers  Interfaces  to  share  die  data.  Also  part  of  die  standard  are  applica¬ 
tion  specific  data  exchange  protocols  called  Application  Protocols.  Application 
Pirotocols  are  normalized  database  definitions,  written  in  EXPRESS,  that  allow 
many  different  applications  to  share  data.  Hie  STEP  standard  has  reached  Draft 
bitemational  Standard  (DIS)  status.  This  means  diat  the  STEP  development 
process  has  been  validated,  along  with  2  Application  Protocols  (201  and  203). 
Some  other  Application  Protocols  under  devdc^mient  include: 

•  AP210  •  Electrcmic  Printed  Circuit  Assembly:  Design  and  Manufacture 

•  AP211  -  Electronic  Printed  Cfrcuit  Assembly:  Test,  Integrated  Diagnostics 
and 

•  Remanufacture 


EXPRESS  has  been  accepted  by  other  standards  groups,  such  as  EDIT,  as  the 
modeling  language  of  choice.  Since  EXPRESS  is  such  a  widely  acc^ted  form  for 
representing  complex  engineering  schemas  and  since  m^iy  of  existing  standard 
data  formats  have  EXPRESS  representations  already  defined  for  them,  this 
makes  tiie  task  of  moving  those  s^emas  into  ROSE  easier. 

This  tight  integration  between  an  accepted  engineering  data  modeling  language 
such  as  EXPRESS  and  an  object-orient^  database  has  the  potential  to  provide  an 
envircmment  of  interoperability  for  botii  MCM  end-users  and  MCM  design  tool 
vendors. 

Tools  Built  on  the  Database  System 

Through  STEP  Tools  there  have  beoi  a  variety  of  tools  build  to  aid  in  the 
development  and  manipulation  of  databases  built  on  ROSE.  EXPRESS 
conquers,  translators  and  editors.  STEP  editors,  browsers  and  conformance 
checkers.  IGES,  DXF  and  ACIS  Translators.  ORACLE,  ObjectStore,  Versant  and 
HP  OpenODB  database  interfaces  are  commercially  available.  There  is  also  a 
database  manager  for  AP203  and  versioning  took  available  from  STEP  tools,  a 
necessary  element  for  conaurent  engineering,  all  with  the  intent  of  providing  a 
superior  engineering/database  development  environment. 
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CFI  Overview 


The  CAD  Framework  Initiative  (CFI)  was  formed  as  a  not-for-profit  industry 
consortia  in  1988.  CFI  is  an  international,  market-driven  organization  whose 
mission  is  to  define  interface  standards  that  facilitate  the  integration  of  design 
automation  tods  and  design  data  for  dte  benefit  of  end-users  and  vendors 
wcnrldwide.  Wifiun  CFI,  a  broad  spectrum  of  international  EDA  (Electronic 
Design  Automation)  users  and  vendor  con^anies  collaborate  to  identify  fi\e 
industry's  most  pressing  integraticm  requirements. 

I¥om  fiiese  requirements,  CFI  members  identify  relevant  existing  standards, 
define  new  areas  for  standardization,  and  work  coqieratively  to  develop  spedfi- 
cations  for  dw  most  urgendy  needed  integraticm  interfaces.  CFI  plays  a  pivotal 
rde  in  moving  the  EDA  industry  toward  dte  ultimate  goal  of  seai^ess  "plug- 
and-play”  assonbly  of  EDA  systems  by  championing  the  inter-c^>erability  and 
inteidu^eability  of  EDA  tools  dirough  common  firamework  interface  stan¬ 
dards. 

CFI  membership  consists  of  over  41  major  corporate  users  of  design  automation 
products,  computer  system  manufacturers,  vendors  of  integrated  design  auto- 
maticm  environments,  and  design  tool  developers,  as  well  as  govenunent, 
research,  and  academic  institutions  in  Nordt  America,  Europe,  and  Asia.  CFI 
corporate  headquarters  is  located  in  Austin,  Texas. 

CFI  1.0  Standards  Support 

The  tdtimate  functicmal  goal  of  CFI  is  to  provide  an  easy  to  use  interchange  of 
individual  EDA  tools  in  a  standards-compliant  firamework  and  enabling  all  these 
tools  to  inter(^>erate  in  the  framework.  To  achieve  this  ambitious  goal,  CFI 
released  the  Version  1.0  Standards  in  January,  1993.  The  1.0  Standards  address 
the  following  key  areas: 

•  Design  Representation 

•  Inter-Tool  Communication 

•  Tool  Encapsulation  Specification 

•  Coixq>uting  Environment  Services 

Overview  of  Design  Representation  Standard  1.0  (DR  1.0) 

The  1.0  Design  Representation  Standard  defines  an  information  model  and  pro¬ 
gramming  interface  for  netlist  manipulation.  DR  1.0  provides  a  common 
methodology  for  standard<ompliant  EDA  tools  and  databases  to  represent, 
access,  and  manipulate  electrical  connectivity  information.  The  number  of 
individual  interfaces  among  CAE  tools  requir^  is  expected  to  be  dramatically 
reduced  with  iiuiustry-wide  support  for  CFI's  DR  1.0. 

A  designer  usii^  DR  l.O-compliant  tools  should  be  able  to  mix-and-match  tools 
wititout  having  to  wony  about  writing  and  debugging  point-to-point  netlist 
translates,  since  all  of  the  toob  share  a  common  information  model  and  pro¬ 
gramming  interface.  Tool  integration  at  the  netlist  level  becomes  much  simpler 
and  less  expensive  for  botii  users  and  veitdors. 
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Overview  of  InteivTool  Communication  Standard  1.0  (ITC  1.0) 

The  1.0  Inter-Tool  Ccmununication  Standard  defines  a  standard  programming 
intoface  and  informatiim  model  which  defines  the  functionality  required  for 
passing  messages  and  information  hrom  one  CAD  tool  to  another.  More 
recently,  there  has  been  a  collaborative  efiort  between  CFI  and  Sun 
Microsystems  to  address  die  possibility  of  replacing  die  ITC  1.0  Standard  with  de 
facto  standard  of  Sun's  ToolTalk  communications  manager.  This  represents  a 
very  positive  activity,  since  diis  same  combination  was  showcased  in  another 
CFI-spcmsored  pilot  project  at  DAC  '92.  Irrespective  of  the  final  decision,  design 
toob  which  conform  to  the  ITC  1.0  Standard  can  communicate  widi  other 
standards-conforming  toob  via  a  message  server.  With  a  standard  mechaiusm 
for  communicating  among  toob,  interoperability  and  data  interchange  will 
become  much  simpler  for  concurrent  process  information  sharing  and  f^back 
among  toob. 

Overview  of  Tool  Encapsulation  Specification  1.0  (TES  1.0) 

The  1.0  Tool  Encapsulation  Specification  provides  a  set  of  format  standards  for 
information  required  to  encapsubte  CAD  design  tools  into  a  single,  consistent 
CAD  framework.  Given  dus  TES  Specification,  toob  from  a  variety  of  vendors 
can  be  incorporated  and  invoked  in  a  consbtent  manner.  Framework  tool-users 
won't  have  to  be  concerned  with  tool  location,  command  syntax,  or  arguments 
required  to  invoke  the  tool.  All  dus  information  b  captured  in  ea^  tool's 
reflective  encapsubtion,  allowing  the  user  to  concentrate  on  the  design  process 
rather  than  tool  details. 

Tool  encapsulation  simplifies  tool  integration,  since  each  specification-compliant 
tool  conforms  to  a  standard  encapsulation,  which  the  tool-user  or  vendor  can 
revise  when  integrating  with  any  additional  CFI-compliant  framework. 

Overview  of  Computing  Environment  Services  Standard  1.0  (CESS  1.0) 

The  1.0  Computing  Environment  Services  Standards  address  base  system  serv¬ 
ices,  system  network  services,  user  interface  guidelines,  extension  languages  and 
error-handling.  Defining  standards  for  platforms  and  networks  makes  moving 
and  interoperating  toob  and  frameworks  across  platforms  much  simpler  and 
less  expensive.  'Thb  standard  b  intended  primarily  for  framework  vendors. 
Integrators  within  each  of  the  various  vendors'  frameworks  will  benefit  if  these 
vendors  are  in  compliance  with  these  environment  services. 

The  STEP  standard  for  product  data  exchange 

bv  a  global  manufacturing  environment,  product  data  needs  to  be  conununicated 
usii^  a  language  that  b  global.  STEP,  the  ISO  10303  Standard  for  the  exchange 
of  p^uct  data,  became  tivat  language  when  it  reached  Efraft  International  Status 
in  February  of  1993.  It  b  expected  to  become  a  full  International  Standard  in 
1994. 

A  standard  that  seeks  to  communicate  complete,  uiuunbiguous,  accvu-ate  defini¬ 
tions  of  producb  around  the  world  caimot  avoid  being  complex.  However,  the 
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basic  organization  of  STEP  is  relatively  simple.  As  shown  in  Figure  3.6,  the  stan¬ 
dard  can  be  broken  into  three  parts:  an  iidrastructure  shown  by  the  bucket  at  the 
base  and  sides  of  die  figure,  a  library  of  engineering  product  model  definitions 
shown  in  the  center  of  tite  figure,  and  a  set  of  application  protocols  shown  at  the 
top  of  the  figure. 
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Figure  3.6  STEP  Standard 
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The  STEP  infrastructure  consists  of  the  EXPRESS  language,  implementation 
methods  and  testing  methods.  In  STEP<  EXPRESS  is  used  to  describe  informa¬ 
tion  modeb.  An  information  model  is  a  formal  description  of  the  information 
requirements  of  an  application  or  set  of  applications.  Information  models  can  be 
described  using  several  different  languages  including  Entity-Relationship  dia¬ 
grams,  NIAM  diagrams  aiul  IDEF  diagrams.  EXPRESS  information  models  use  a 
program-like  notation  as  dieir  primary  form  and  a  diagram  notation  called 
EXPRESS-G  as  an  illustrative  form.  EXPRESS  is  distinguished  from  other  infor¬ 
mation  modeling  languages  by  its  use  of  a  program-like  notation,  by  its 
extensive  iise  of  inheritance  and  by  its  ability  to  describe  user-defined 
omstraints.  Some  examples  of  EXPRESS  are  given  in  the  fourth  section. 

EXPRESS  describes  the  properties  required  in  a  body  of  information,  now  how 
they  are  represented  in  a  system.  This  leaves  applications  free  to  describe  data¬ 
bases  that  use  this  information  in  many  difrdrent  ways.  Applications  that  want 
to  use  this  information  in  standard  ways  use  one  of  the  STEP  implementation 
mefriods.  Currently,  they  consists  of  a  file  format  (Part  21)  and  an  applicatiL/i 
programmers  interface  (Standard  Data  Access  Interface-SDAI).  The  SDAI  is  an 
abstract  description  of  a  set  of  operations  that  can  be  applied  to  a  database 
defined  by  an  EXPRESS  information  model,  and  bindings  for  these  operations  in 
d\e  C,  C-f  and  FORTRAN  programming  languages. 

The  library  of  engineering  product  model  dehiutions  shown  in  the  center  of  the 
figure  will  eventually  contain  one  definition  for  every  kind  of  entity  used  in 
engineering  applications.  The  library  is  divided  into  a  series  of  parts  that 
describe  definitioirs  for  particular  kinds  of  engineering  data.  For  example.  Part 
41  contains  definitions  for  configiuation  management.  Part  42  contains  defini¬ 
tions  for  geometry,  and  Part  45  contains  definitions  for  materials.  The  library  is 
large  and  growing.  Whenever  a  new  Application  Protocol  is  added  to  STEP  the 
designers  of  that  protocol  must  first  m^e  sure  that  the  library  contains  the 
resources  that  will  be  needed  by  the  protocol.  If  it  does  not,  then  a  new  Part 
must  be  added  to  the  library. 

The  global  library  is  too  compreheitsive  for  any  single  application  or  set  of  appli- 
caticms.  Therefore,  the  definitions  in  die  global  library  are  assembled  into  useful 
subsets  by  the  Application  Protocols.  Each  Application  Protocol  contains  all  the 
definitions  tiiat  are  necessary  and  sufficient  to  describe  a  particular  kind  of 
product  for  a  particular  range  of  applications.  For  exan^le,  AP203  contains  all 
tile  definitions  needed  to  describe  configuration  controlled  mechanical  assem¬ 
blies  and  AP207  contains  all  of  the  definitions  needed  to  describe  sheet  metal 
dies. 

The  global  library  and  the  Application  Protocols  in  STEP  are  described  using 
EXPRESS.  New  application  Protocob  are  added  to  STEP  using  a  three  stage 
process.  In  tiie  fint  stage,  the  applications  that  will  be  using  the  Application 
Protocol  are  identified  using  an  Application  Activity  Model  (AAM).  ^  the  sec¬ 
ond  stage,  the  entities  tiuit  need  to  shared  by  these  applications  are  identified 
by  application  experts.  These  expats  produce  a  preliminary  model  called  the 
Application  Resource  Model.  Normally,  the  application  experts  produce  an 


ARPA  Market  Study  —  Technology 


Section  3  •  Page  18 


EXPRESS  model,  but  at  this  stage  they  may  also  choose  to  use  NIAM.  Finally  in 
die  iidtd  stage  STEP  experts  normalize  this  model  to  create  a  final  model  called 
file  Application  Interpreted  Model  (AIM).  These  models  are  always  written  in 
EXPRESS. 

In  tfte  nonnalization  process,  fi\e  STEP  experts  select  an  entity  from  die  global 
library  to  represent  every  entity  in  d\e  ARM  model  product  by  dw  domain 
experts.  If  an  appropriate  entity  does  not  exist  dien  one  is  added.  They  also 
reorganize  die  ARM  model  so  diat  as  many  constraints  as  possible  axe  repre¬ 
sent^  by  the  standard  data  structures  and  constraints  of  EXPRESS.  Next  ^ey 
try  to  eiqpxess  as  many  of  die  remaining  constraints  as  possible  using  "local"  user 
defined  rules  diat  apply  to  a  single  entity.  Finally,  die  reaming  constraints  are 
represented  by  "global"  user  defined  rules  that  apply  to  a  database  of  entities. 

The  STEP  nonnalization  process  produces  Application  Protocols  for  well  defined 
sets  of  applications.  Currendy  approximately  25  Applicon  Protocols  are  in  vari¬ 
ous  stages  of  the  standardization  process.  Many  of  these  Application  Protocols 
contain  overlapping  subsets.  Therefore,  the  STEP  community  has  created  Appli¬ 
cation  Interpreted  Constructs  (AlC's)  to  formalize  diese  subsets.  For  example, 
die  boundary  representation  geometry  in  Application  Protocol  203  is  defined  by 
an  Application  Interpreted  Construct  so  diat  other  protocols  can  use  this 
geometry. 

If  an  AIC  is  the  same  as  a  generic  resource  in  the  global  library,  then  the  defini¬ 
tion  of  that  AIC  is  simple.  However,  in  practice  AIC's  are  different  to  generic 
resources  because  the  former  are  instantiations  of  the  latter  in  specific  contexts. 
For  exarxqile.  Part  42  of  STEP  contains  definitions  for  many  different  kinds  of 
geometry.  Some,  but  not  all,  of  this  geometry  is  used  in  boundary  representation 
models.  Therefore,  the  geometry  model  in  Part  42  is  distinct  from  the  boundary 
representation  AIC. 

Electronic  Design  Interchange  Format  (EDIT) 

EDIF  is  a  representation  of  electronic  design  data  that  primarily  addresses  CAE 
data  representation  including  electronic  logic,  schematic  diagrams,  electronic 
simulation  data.  EDIF  is  endorsed  by  die  Electronic  Industries  Association  (EIA) 
and  Electronic  Design  Automation  Companies  (EDAC). 

Since  1988,  EDIF  has  been  maintained  using  the  EXPRESS  language.  An 
EXPRESS  information  model  of  the  EDIF  format  has  been  established.  Changes 
at  additions  to  EDIF  submitted  for  implementation  are  accepted  only  as  new  or 
modified  EXPRESS  information  model. 

The  CHOICE  EXPRESS  information  model  could  be  expanded  to  include  EDIF. 
Conversely,  the  CHOICE  ixiformaticni  model  contains  MCM  design  and 
manufacturing  ixiforxnation  diat  could  be  an  extension  to  the  EDIF  model. 
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Initial  Graphics  Exchange  Specification  (ICES) 

Initial  Graphics  Exchange  ^jedficaticm  (IGES)de£ines  a  file  structure  format,  a 
lai^age  format,  and  the  representation  of  geometric,  U^logical,  and  non¬ 
geographic  product  definition  data  in  these  formats.  It  provides  a  digital 
representation  and  communication  of  product  definitions.  Use  of  the  IGES 
^XKification  permits  the  con^jatible  exchange  of  product  definition  data  used  by 
various  CAD/CAM  systems. 

IGES  is  used  extensively  in  fite  mechanical  design  and  CAD  industry  and  to  a 
lesser  extent  in  die  electronic  design  automation  industry.  It  serves  a  one  means 
to  transfd:  data  between  electronic  design  and  mechanic^  design  systems. 

An  EXPRESS  information  model  for  IGES  has  been  developed.  CHOICE  uses 
the  IGES  format  as  output  by  Cadence  Allegro  to  interface  with  ROSE.  This 
in^lementation  is  a  small  sub^  of  dte  total  IGES  format. 

Current  Commercial  Products 

Mentor  OpenDoor 

Mentor  Graphics  Corporation  ofiers  the  "Open  Door"  program  that  allows  EDA 
Software  vendors  dte  ability  to  incorporate  oftware  tools  with  Mentor  Graphics 
software  tools.  OpenDoor  gives  its  participants  access  to  Mentor's  Falcon 
Framework  product,  select  applicatioiijc  wit^  the  firamework  and  software 
toolkits  to  access  the  selected  appUcaticms  data. 

The  OpenDoor  program  allows  participants  to  perform  the  following  tasks  to 
integrate  their  tools  with  Mentor  Graphics'  tools  and  environment. 

•  Tool  encapsulation.  This  allows  a  participant  to  register  tools  in  the  Falcon 
Framework.  This  encapsulation  is  accomplished  via  an  AMPLE  script, 
which  is  Mentor's  extension  language,  ^ecution  of  the  tool  fiom  ^e 
firamework  is  then  possible. 

•  Data  Access.  Data  access  is  accomplished  via  Programming  Toolkits  that 
allow  participants  to  read  and  write  Mentor  application  data.  An  example  of 
one  of  Mentor's  toolkits  is  DFI.  This  toolkit  provides  a  procedural  interface 
to  the  Design  Architect  database. 

•  Interprocess  communication.  Participants  can  pass  messages  to  and  from 
Mentor  applications.  These  messages  can  be  passed  either  via  a  File  or  via 
Berkeley  sockets.  The  file  based  methc^  of  passing  messages  is 
accomplished  fivough  AMPLE  scripts.  The  socket  based  method  is 
accomplished  fiut>ugh  a  procedural  interface. 

•  Design  Data  Management.  Dedgn  data  management  is  accomplished  in  a 
similar  fashion  to  tool  encapsulation.  Any  application's  data  files  can  be 
encapsulated  into  die  framework  similar  to  tools.  Once  the  different  data 
files  are  encapsulated,  tools  can  be  executed  through  the  data,  versioits  of  the 
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data  can  be  created,  aiui  references  can  be  created  between  different  versions 
of  data  files.  These  versions  and  references  can  be  created  numually  by  the 
user  or  automatically  when  a  tool  completes  execution. 


■ 


Viewlogk  PowerPartners 

Viewlogic  Cosporatim  offers  the  TowerPartners"  program  that  allows  EDA 
Software  vendors  die  ability  to  incorporate  software  toob  along  widi  Viewlogic 
software  tods.  PowerPartners  gives  its  participants  access  to  Viewlc^c's 
framework  product  PowerView,  selected  applications  and  software  toolkits  to 
access  die  selected  applications  data. 

The  PowerPartners  program  allows  participants  to  perform  the  following  tasks 
to  integrate  dieir  took  with  Viewlogic's  took  and  environment. 

•  Tool  encapsulation.  Thk  allows  a  participant  to  regkter  took  in  PowerView. 
Thk  encapsulation  k  accomplished  via  CFI  TES  1.0  standard.  Execution  of 
the  tool  from  the  framework  k  then  possible. 

•  Data  Access.  Data  access  k  accomplished  via  Programming  Toolkits  diat 
allow  participants  to  read  and  write  Viewlogic  applicaticm  data.  An  example 
of  one  of  Viewlogic's  toolkits  k  PCB  Toolkit  This  toolkit  provides  a  proce¬ 
dural  interface  to  die  Viewdraw  database  for  the  purposes  of  interfacing  with 
PCB  CAD  products. 

•  Interprocess  communication.  Participants  can  pass  messages  to  and  from 
Viewlogic  applications.  These  messages  can  be  passed  either  via  a  File,  X- 
events  or  UNIX  fifo's.  The  file  based  mediod  of  passing  messages  is 
accomplished  through  a  product  call  CPROBE. 

•  Design  Data  Management.  Design  data  management  k  accomplished  with  a 
product  call  PowerViewDM.  The  design  data  k  described  to  PowerViewDM 
through  a  text  file.  Any  application's  data  files  can  be  encapsulated  into  the 
framework  similar  to  took.  Once  the  different  data  files  are  encapsulated 
dien  versions  of  die  data  can  be  created  either  manually  by  the  user  or  auto¬ 
matically  when  a  tool  completes  execution. 

Cadence  Connections 

Cadence  Corporation  offdrs  the  "Connections"  program  that  allows  EDA 
Software  vendors  die  ability  to  incorporate  software  took  along  with  Cadence 
software  took.  Connections  gives  its  participants  access  to  Cadence's  Design 
Framework  II  product,  select^  Cadence  applications  and  software  toolkits  to 
access  die  selected  applications  data. 

The  Connectimis  program  allows  participants  to  perform  the  following  tasks  to 
integrate  their  took  widi  Cadence's  took  and  environment. 
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•  Too/  encapsulation.  This  allows  a  participant  to  register  tools  in  Design 
Framework  H.  This  encapsiilaticxn  is  accomplished  via  a  SKILL  program, 
which  is  Cadence's  extension  language.  Execution  of  die  tool  from  the 
framework  is  then  possible. 

•  Data  Access.  Data  access  is  accomplished  via  Programming  Toolkits  that 
allow  participants  to  read  and  write  Mentor  application  data.  An  exan^le  of 
(me  of  Cadence's  toolkits  is  CAEViews.  This  toolkit  provides  a  prcxr^ural 
interface  to  die  Concept  database. 

•  Interprocess  communication.  Participants  can  pass  messages  to  and  from 
Cadence  applications.  These  messages  can  be  passed  via  Berkeley  s(x:kets. 

•  Design  Data  Management.  Design  data  management  is  accomplished  with  a 
product  call  Teamwork.  Any  applicati(m's  data  files  can  be  encapsulated 
into  die  framework  similar  to  tools.  Once  the  difrerent  data  files  are 
encapsulated  then  versions  of  the  data  can  be  created,  and  relationships  can 
be  created  between  different  versions  of  data  files. 

DICE  Programs 

MCAf  Concurrent  Engineering  Environment 

ROSE  has  been  exercised  in  a  variety  of  applicaticm  envircmments.  ROSE  has 
been  positioned  as  a  mechanism  for  design  data  interchange  and  has  demon* 
strated  its  ability  to  move  data  between  ^s*similar  design  environments  (e.g., 
FINESSE  MCM,  Valid  Allegro,  AutoCad,  Cadence  Edge). 

ROSE  is  also  being  used  in  more  of  an  interactive  tool  environment  within 
Raytheon.  In  the  Raytheon  envircmment  the  data  is  being  moved  from  their 
internal  database  to  ROSE  in  order  to  perform  manufacturing  yield /cost  analysis 
on  the  data. 

This  diversity  of  working  environix^ts  has  exercised  the  ROSE  environment  in 
many  different  wa3rs.  The  diversity  of  tiie  environments  has  demonstrated  that 
ROSE  has  the  potential  to  be  used  for  many  applications  within  engineering 
domain. 

A  review  of  the  DICE  Projecrt  involving  the  use  of  ROSE  as  the  underlying  data¬ 
base  will  discuss  the  benefits  and  shortcomings  of  the  DICE  technology  as 
compared  with  the  other  commercially  available  database  and  concurrent 
engineering  technology. 

An  assessment  of  how  DICE  could  be  further  developed  to  meet  the  needs  and 
expectation  of  the  end-users  will  be  stoted. 
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Manufacturing  Optimization 

Ra]rtt\eoin  Con^Mmy  Manufacturing  Optimization  (MO)  System  was  devel<^>ed 
tinder  DICE  funding  and  will  be  delive^  by  1st  quarter 

The  MO  System  was  developed  to  enable  manufacturing  engineers  and  special¬ 
ists  toe  ofs^ortunity  to  participate  as  a  group  in  toe  design  process.(Figure  3.7) 
The  system  consists  of  a  set  of  tools  toat  model  printed  circuit  board 
manufacturing  processes  and  toen  centralizes  toe  various  tradeoffs  caused  by 
toe  manufacturing  processes.  (Figure  3.8) 

Ihe  manufacturing  team,  using  toe  MO  System,  can  pass  recommendatitms 
based  on  toe  number  of  results  created  by  toe  MO  System  back  to  the  product 
design  t«un.  These  recommendaticms  come  from  toe  multidisdplined 
rrumufacturing  team  as  opposed  to  a  select  f^  manufacturing  representatives. 
In  tois  way,  processes  like  pc  board  feibricaticm,  drilling,  component  pick  and 
place,  soldering,  automatic  test,  and  many  other  disciplines  can  have  their 
unique  experience  included  in  toe  analysis  and  f^back. 

The  MO  System  utilizes  toe  same  ROSE  database  and  STEP  Tools,  Inc. 
environment  as  toe  CHOICE  concurrent  engineering  envirorunent.  (Figure  3.9) 


figure  3.7  Raytheon  Mamfacturmg  Optimization  Concept 
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Figure  3.8  Faytheon  Concurrent  Engineering  Environment 
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Introduction 

Harris  CASD  Experience 

Harris  GASD  Government  Aerospace  Systems  Division  (Harris  GASD)  is  a 
major  designer  and  sillier  of  advaiKed  electronics  for  the  DoD  and  NASA 
communities.  Harris  GASD  has  actively  engaged  in  die  design  and  develop¬ 
ment  of  state-of-die-art  mulddiip  modules  for  use  in  military  systems.  Starting 
in  1990,  Harris  GASD  has  cosx^leted  designs  for  fourteen  diderent  MCMs  for 
use  in  five  major  military  programs. 

The  systems  include  die  F-22  AdvarKed  Tactical  Fighter  for  the  U.S.  Air  Force, 
and  ^  RAH-66  Comanche  Light  Helicopter  for  the  U.S.  Army.  For  the  F-22, 
Harris  GASD  is  supplying  all  of  die  aircraft's  Fiber-Optic  (F-O)  avionics  inter¬ 
faces  using  diree  F-O  MCMs.  These  MCMs  are  excellent  exan^les  of  mixed 
tedindogy  MCMs  which  combine  die  digital,  analog  and  mixed  sigiud  features 
of  CMOS,  Bipolar,  GaAs  and  FibaOpdc  circuit  technologies  into  a  single  mod¬ 
ule.  The  wise  exploitation  of  this  evolving  MCM  technology  will  help  to  the 
manage  costs  while  improving  dw  technical  performance  of  future  weapon 
systems. 

Harris  GASD  has  identified  MCMs  as  a  core  technology.  Harris  GASD  has  made 
a  commitment  to  the  use  of  MCMs,  because  they  provide  an  important  key  to  the 
success  of  future  programs. 

Background 

Concurrent  Et^ineering  Overview 

Traditional  functional  (organizations  such  as  engineering,  testing,  prcxluct  assur¬ 
ance  and  manufacturir^  have  maintained  their  expertise  by  ccmcentrating  their 
skills  in  (me  area.  The  functional  organizational  structure  has  the  advantage  of 
maintaining  and  enhancing  expert  in  a  given  area  and  enabling  good 
communication  within  that  area.  The  difficulty  with  this  structure  is  that 
projects  progress  serially  and  the  communicati(m  is  inefficient  among  the  larger 
organizaticms.  These  d^dendes  maybe  rectified  by  establishii^  program  teams 
with  people  from  each  of  die  functitmal  organizations  working  together  on  a 
concurrent  engineering  team.  Harris  GASD  has  used  this  multi-disdpline 
concurrent  engineering  approach  to  successfully  complete  fourteen  MCM 
designs.  The  application  of  concurrent  engineering  teams  has  reduced  design 
cyde  times  and  helped  to  (xmtain  costs. 

In  die  design  of  the  MCMs,  die  program  team  members  work  in  parallel  to 
cooq>lete  die  product  design  wid^  die  minimum  amoimt  of  time.  Since  an 
(^ti^  MCM  design  environment  is  still  emerging,  a  Cadence/Valid  Logic  plat¬ 
form  was  used  as  the  MCM  design  baseline.  Other  ancillary  t(X>ls  were  used  in  a 
piecemeal  fashitm  to  analyze  analog  functions  and  other  bdiavioral  performance 
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characteristics  not  fully  supported  by  the  Cadence  toolset.  The  design  effort  for 
ttieae  craz^lex  MCM  devices  has  required  the  use  of  multiple  software  tools 
from  a  variety  of  different  tool  suppliers. 

Scope  of  Report 

llus  application  of  die  concurrent  engineering  envirrxunent  will  be  described  in 
tttis  report  as  we  discuss  the  various  MCM  prqects  in  detail.  This  report  will 
describe  die  MCM  design  methodology  and  software  tools  used  at  Harris  GASD 
to  oooqilete  electronic  systems  design  projects  duit  utilize  MCM  technology. 
Case  studies  taken  from  various  Har^  GA^  programs  will  be  used  to  explore 
die  software  tods  features,  design  database  capabilities,  data  transfer  require¬ 
ments,  design  to  manufficturing  issues,  MCM  test  data  generation,  and  timelines 
to  project  completion. 

This  report  wiU  also  describe  die  desired  MCM  Design  Environment  diat  would 
support  an  efficient  and  effective  MCM  design  mediodology.  The  report  will 
dim  highlight  the  expected  improvements  in  terms  of  reduced  MCM  design 
cycle  time,  fewer  design  iterations,  greater  product  performance  and  reduced 
overall  product  costs.  The  desired  MCM  Design  Environment  will  include  a 
description  of  desired  autonudc  features,  software  requirements,  concurrent 
ei^ineeting,  data  integration  among  applications  and  manufacturing,  and  other 
aspects  of  ^  "should  be"  envinximent. 

MCM  Applications 

Using  the  concurrent  engineering  coiKept,  Harris  GASD  has  designed  fourteen 
diffeimt  MCMs  diat  are  used  in  five  izu^  military  programs.  Over  the  next 
twelve  mondis  Harris  GASD  will  be  delivering  military  systems  which  contain 
over  3,000  MCMs.  These  fourteen  MCMs  can  be  classified  into  three  categories: 
Digital,  Mixed  Digital /Analog  and  Fiber-Optic/Mixed  Signal. 
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PROGRAM 

MCM  DESCRIPTION 

COMMENTS 

kVi(»ucs  Technology 
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rilliantEyes 


:.rx2.r 

OMHz 
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J.S.  Army  Light 
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igital  Drop  Receiver 
8”x2.8"  MCM 
SMHz 
5  ASICs 
EE  PROM 
08  I/Os 


ocessor  MCM 
.8"xl.8" 

SMHz 

-CMOS  ASICs, 
04  I/Os 


issembly,  bum-in,  and  test  completed 
tt  Harris  GASD  GASD. 
Muminum/polyamide  substrates 
abricated  by  Hughes.  MCMs 
ompleted  in  September  93. 


w  Ten^rature  Cofired  Ceramic 
(LTCC)  Substrates  Metal  Packages. 
MCMs  Design,  layout,  and  testing 
ompleted  at  Harris  GASD  GASD. 
TCC  substrates  and  MCM  assembly 
rformed  by  CTS,  a  Harris  GASD 
ASD  partnership  supplier. 

MCM  working  prototypes  completed 
November  93. 


roject  built  a  base  for  military 
ualifiable  MCM  processes  and  piece 
3arts  for  both  Class  H  and  K.  MCMs 
>eing  fabricated  in  LTCC,  HTCC,  and 
rPML.  Electrical  testing,  bum-in,  and 
ualification  testing  being  performed 
y  Harris  GASD  GASD. 
fCMs  completed  in  November  93. 


w  temperature  cofired  ceramic 
(LTCC)  substrate  with  integrated 
ackage.  Design,  layout,  and  testing 
rformed  at  Harris.  LTCC  substrates 
d  MCM  assembly  performed  by 
CTS,  a  Harris  GASD  partnership 
upplier.  MCM  working  prototypes 
ompleted  in  July  93.  First  production 
CMs  completed  Nov.  93. 


Table  4.1  Description  cf  Harris  GASD  Digital  MCMs  by  Program 
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HARRIS  DDR-2  BUILT  IN  THREE  MCM  TECHNOLOGIES 


Figure  4.2  Harris  DDR-Z 
Built  in  three  MCM  Technologies 


Figure  4.3  93-2100CMR-1-6A 
Comanche  Processor  Module 


Comanche 

U.S.  Army  Light 
Helicopter 

2  MCMs 

1.8"x  Harris  GASD  GASD304 
I/Os 

Sensor  Data  Distribution 
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- 1  Analog  ASIC 

High  Speed  Data  Bus 
(HSDB) 

100  MHz 
-1  CMOS  ASIC 
-lECLASIC 
-4  SRAMS 

Low  temperature  cofired  ceramic 
(LTCC)  substrate  with  integrated 
package.  Design,  layout,  and  testing 
performed  at  Harris  GASD  GASD. 
LTCC  substrates  and  MCM  assembly 
performed  by  CTS,  a  Harris  GASD 
GASD  partnership  supplier.  MCM 
working  prototjn^s  completed  in 

July  93.  First  production  MCMs 
completed  Nov.  93. 

Sub-Miniature 

2  MCMs 

Low  Temperature  Cofired  Ceramic 

Telemetry 

2.0"  X  2.0" 

(LTCC)  Substrates  in  metal  packages. 

(SMT) 

40  I/Os 

MCMs  Design,  layout,  assembly  and 

2  MHz  to  2.4  GHz 

testing  accomplished  at  Harris 

1  RF  ASIC 

GASD  GASD.  Modules  were 

2  Analog  ASICs 

successfully  completed  in  February 

1  Digital  ASIC 

1993. 

Table  4.2  Description  of  Harris  GASD  Mixed  Signal  MCMs  by  Program 
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Figure  4.4. 93-21000-1-DA 
Comanche  SDDN 


Fiber-Optic /Mixed  Signal  MCMs  by  Program 

PRCX3RAM 

MCM  DESCRIPTION 

COMMENTS 

F-22  U.S.  Air  Force 

3  MCMs 
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(FOTX) 
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completed  in  Feb.  93.  First 
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Fiber-Optic  Receiver 
(FORX) 

-100  I/O 

-  l,0"xl.5" 
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-1  CMOS  ASIC 
-1  ECL  ASIC 
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- 1  GaAs  ASIC 

High  Speed  Data  Bus 
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-1  CMOS  ASIC 
-1  ECL  ASIC 
-4SRAMS 

-  4  Analog  ASICs 

-  4  Detachable  Fiber-Optic 
cables 

Tobte  4.3  Description  ofFiber-Optic/Mixed  Signal  MCMs  by  Program 
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Figure  4.9.93-0834C 
F22  Fiber  Optic  Receiver 


Design  Environment 

Design  Environment  Overview 

Figure  4.10  shows  a  diagram  of  die  current  MCM  design  environinent  at  Harris 
GASD.  The  '^CM  Constraints’*  and  the  “Chipset  and  Electrical  Interconnect" 
requirements  provide  die  iiqiut  data  which  drive  die  toolset  of  MCM  design 
process.  The  MCM  constraints  include  die  MCM  supplior's  design  rules,  die  per- 
fonnance  duuacterisdes  whidi  flow  from  the  custonwr's  requirements,  and  odier 

constraints  on  die  MCM  design- 

Under  die  concurrent  engineerir^  model,  the  MCM  frdirication  and  assembly, 
test  vector  generation,  MCM  test  and  rework,  Pro(rf-of>Design  (POD)  evaluation 
and  die  transition  to  system  level  manufacturing  are  all  considered  to  be  a  part 
of  die  MCM  design  process.  All  of  the  engineering  disciplines,  including  design, 
test,  manufrKtuiing  and  product  assurance  are  closely  coupled  during  all  stages 
of  diis  process. 

Managing  die  material  and  parts  aspects  of  an  MCM  assembly  is  also  an  integral 
part  of  die  design  environment,  llie  ^proved  Parts  Interactive  Management 
System  (APIMS)  provides  a  general  database  widi  extensive  information  regard¬ 
ing  aj^proved  suppliers  and  standard  parts  for  use  in  deliverable  hardware. 
APIMS  also  creates  a  direct  link  into  our  purchasing  organization  and  aids  in 
device  procurement  activity.  The  Parts  Control  and  Tracking  System  (PCATS) 
manages  the  parts  lists  at  die  module,  PWB  and  box  level  for  each  individual 
assembly  efrort  required  to  conqilete  a  Harris  GASD  contract.  The  Integrated 
Manufricturing  Operating  System  (MOS)  coordinates  and  manages  the  overall 
manufacturing  effort,  using  parts  status  information  extracted  from  PCATS  plus 
real-time  assembly  status  infbrmaticm. 

The  PCA’TS  and  APIMS  toob  were  bodi  developed  internally  at  Harris,  because 
we  could  not  find  commercial  software  which  met  our  nee^.  The  IMOS  tool 
was  purchased  as  a  standard  software  product. 
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As  is  illustrated  by  Figure  4.11,  dvere  is  a  plethora  of  ccmstraint  systems  which 
drive  the  MCM  design  and  layout  process.  The  essence  of  the  MCM  design 
process  is  dte  applicati<xi  of  the  design  tools  towards  the  goal  of  achieving  the 
comprcunise  solution  which  best  satisfies  these  constraints.  The  customer 
requirements  drive  the  selection  of  devices  and  technologies  which  define  fite 
"Chipset  and  Electrical  Interconnect"  criteria.  The  required  electrical  perform- 
aitce  characteristics,  mechanical  restrictions,  atul  dtermal  issues  all  push  the 
design  features  (what  is  desired),  while  die  chipset  requirements  and  MCM 
supplier's  rules  constrain  the  MCM  layout  process  (what  can  be  built).  The  toob 
diemselves  add  anodter  byer  of  constraints,  and  die  design  process  cannot 
ignore  die  limitations  impoMd  by  d«se  simulation  toob.  The  MCM  assembly 
capabilities  and  die  test  hardware  add  a  final  byer  of  restrictions:  die  design 
must  be  buildable  and  tesbble. 

The  essence  of  concurrent  engineerir^  b  to  manage  all  of  these  various  con- 
strainte  in  parallel,  to  avoid  design  iterations.  Thb  b  accomplished  at  Harrb 
GASD  by  bringing  together  the  disciplines  responsible  for  each  of  the  individual 
constraint  systems,  and  assembling  them  into  a  design  team. 
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Figun  4.11.  MCM  Design  Flow  Showing  Interaction  with  External  Constraint  Systems 

Software  Tool  Sets 

To  manage  a  plediora  of  constraint  systems,  one  needs  a  plethora  of  tools. 
Figure  4.12  sh^s  an  example  of  dte  key  software  tools  wHch  ate  currently 
applied  to  a  typical  MCM  design  at  Harris  GASD.  This  software  tool  set  may  be 
modified  or  extended  to  meet  specific  program  requirements. 

The  Ca(tence/Valid  Logic  design  platform  forms  the  core  of  the  MCM  design 
envinmment  ¥ot  most  of  our  digital  ASIC  devices,  the  Synopsis  tool  is  used  to 
synthesize  an  ASIC  design  from  VHDL  or  another  high  level  model,  for  a  target 
ASIC  tedmology.  The  resviltmg  ASCII  netlist  is  ported  into  the  Cadence  plat¬ 
form  using  SYNUNK  Hardware  modelers  are  used  to  bring  in  standard  IC 
devices.  Functicmal  and  behavioral  simulations  are  performed  using  the  Valid 
Logic  Rapidsim  timing  simulator  and  the  LMSI  tools.  TESTSCAN  or  SIMUTEST 
{or  ofirer)  tools  are  us^  to  generate  scan  sequences  for  structural  testing.  The 
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NKZM  layout  is  maiuged  using  Allegro.  TSSI  is  used  to  translate  the  simulation 
results  into  test  vector  patterns  for  use  on  Ae  HP82000  test  system.  A  variety  of 
odier  tools  are  required  to  simulate  mixed  signal  and  analog  drcxiitry,  and  to 
address  thermal  and  mechanical  issues.  The  APIMS,  PCATS  and  IMOS  tool  sets 
are  needed  to  manage  the  manufacturing  effort  from  parts  procurement  through 
final  assembly  and  testing. 

Each  ci  dtese  tools  requires  an  elaborate  database  structure  to  manage  the  vast 
quantities  of  data  associated  with  the  design  of  a  coo^lex  MCM  device.  Some  of 
dtese  tools  have  limited  capability  to  share  information,  but  as  a  general  rule 
each  tool  has  an  independent  database.  Data  is  carried  fi*om  one  tool  to  another 
via  dedicated  traitslation  tools.  This  lack  of  synergy  makes  multiple  chip  simu¬ 
lation  efforts  at  dw  MCM  level  very  tedious.  Different  technologies  within  the 
MCM  must  be  simulated  wid\  different  tools  in  a  piecemeal  fashion,  and  the 
results  must  dten  be  ported  over  to  other  simulation  tools.  While  dus  segmented 
design  approach  has  been  successful  on  the  MCM  designs  completed  by  Harris 
GASD,  d\e  lack  of  truly  concurrent  design  platform  has  limited  d\e  ability  to 
perform  rigorous  MCM  level  simulations.  The  existing  tools  cannot  simulate  all 
of  the  digital,  analog  and  fiber-optic  functions  of  the  MCM  simultaneously. 
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Figure  4.12  Scfftvoare  Tool  Set  Interaction 
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MCM  DESIGN  ENVIRONMENT  CASE  STUDIES 


Design  to  Manufacturing  Issues 

There  are  two  sets  of  manufacturing  issues  which  are  salient  to  MCM  designs: 

1.  The  MCM  itself  must  be  producible  and  testable  as  a  stand-alone  device. 

2.  The  behavior  of  die  MCM  must  be  fully  imderstood  at  the  next  highest 
assembly  level;  which  is  usually  a  printed  wiring  board. 

The  narrative  which  follows  provides  a  detailed  study  of  how  MCM  technology 
has  been  implemented  for  Harris  GASD  programs. 

Brilliant  Eyes  MCMs 

In  the  "Brilliant  Eyes"  program,  Harris  GASD  designed  very  dense 
radiation-hardened  main  processor  memory  and  cache  memory  modules  for 
application  on  space  platforms.  We  were  able  to  develop  or  obtain  sufficiently 
accurate  functional  and  timing  models  for  all  the  memory  and  logic  elements 
used  in  the  MCM  designs,  in  formats  compatible  with  the  Cadence/Valid  Logic 
platform.  This  allowed  electrical  design,  layout,  simulation  and  back  annotation 
to  be  performed  on  one  common  design  platform.  The  advantage  was  that  the 
same  suite  of  design  and  simulation  tools  could  be  applied  to  the  different  levels 
of  hierarchy  from  the  die  level  behavior  up  to  the  total  MCM  function. 

There  were  no  difficult  thermal  issues,  so  the  design  constraints  were  driven  by 
die  rules  of  the  module  supplia  (CIS)  and  by  the  system  performance  require- 
maits  (size,  memory  access  and  cadie  speed,  power  and  weight).  The 
application  of  a  concurrent  engineering  methodology  was  straightforward. 
Representatives  from  the  various  Harris  GASD  design  disciplines  (electrical, 
mechanical,  quality  and  reliability)  worked  with  the  manufacturing  engineers  at 
CIS  to  develop  a  set  of  manufacturing  rules.  These  rules  were  summarized  by 
Harris  GASD  and  entered  into  the  Valid  Logic  layout  tools.  This  approach 
allowed  the  Valid  platform  to  operate  as  a  constraint  driven  design  system. 

This  constraint  driven  design  environment  allowed  the  use  of  technical  level 
specialists  to  perform  the  detailed  MCM  layout,  with  only  minimal  supervision 
from  engineering  level  personnel.  This  use  of  less  expensive  persoimel  reduced 
the  NRE  costs  of  the  MCM  design.  The  Allegro  tool  was  able  to  export  the  lay¬ 
out  netlist  information  in  a  format  compatible  with  the  CIS  process.  The  first 
Proof-of'E>esign  (POD)  units  delivered  by  CTS  had  good  substrates  and 
functioned  correctly. 

AHATMCMs 

The  intent  of  the  Advanced  Hardened  Avionics  Technology  (AHAT)  Program  is 
to  demonstrate  digital  processor  technology  for  extremely  high  radiation  envi¬ 
ronment  military  space  applications  (actud  levels  are  dassihed).  The  MCM 
design  employed  a  combination  of  Silicon-on-Sapphire  (SOS)  ASIC  devices,  and 
standard  CMOS/epitaxial  technology  chips  sudi  as  memory  and  a  MIL-STD- 
1553  bus  controUer. 
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The  MCM  and  ASIC  level  designs  needed  to  be  performed  in  parallel  because  of 
very  tight  schedule  and  budget  constraints.  Design  iterations  could  not  be  toler¬ 
ated.  The  logic  partitions  and  die  footprints  were  frozen  early  in  the  MCM 
design  process,  requiring  the  ASIC  level  designs  to  fit  into  the  allocated  substrate 
areas.  The  die  level  gatecount  estimates  whi^  were  designed  to  be  conservative 
later  proved  to  be  low,  which  caused  painful  tradeo^  between  die  size  and 
desir^  functions. 

The  digital  ASICs  were  all  designed  using  the  Genesil  Silicon  Compiler  on  a 
Mentor  Graphics  platform,  wifo  libraries  for  foe  Harris  GASD  Semiccmductor 
TSOS4  technology.  There  was  good  Uitkage  between  foe  target  technology  and 
foe  simulation  toob  at  foe  die  level,  but  foe  Mentor  Graphics  tools  proved  imma¬ 
ture  at  foe  multiple  chip  simulaticm  level.  We  experienced  reasonable  success  in 
migrating  circuit  mod^  from  foe  die  to  module  level,  but  foe  total  gate  count 
exceeded  foe  capacity  of  the  simulation  tools.  We  also  needed  to  develop  behav¬ 
ioral  modeb  for  foe  standard  logic  parts,  which  included  memory  chips,  and  a 
MIL-  STD-1553  bus  controller. 

Throughout  foe  ASIC  and  MCM  level  design  cycles,  weekly  meetings  were  held 
with  all  disciplines  represented,  including  foe  ASIC  supplier  (Harris 
Semiconductor)  and  foe  substrate  suppliers  (Raychem,  later  replaced  by 
Hughes).  The  Thin-Film  Multi-Layer  (TF^)  substrate  design  was  passed  off  to 
Hughes,  who  delivered  bare  aluminum/polyamide  module  substrates.  Non¬ 
standard  grovmd  planes  were  required  for  radiation  hardness,  which  caused 
negotiation  of  design  rules  with  foe  substrate  supplier.  The  subsequent  assem¬ 
bly,  testing  and  rework,  bum-in  and  final  testing  were  all  performed  at  Harris 
GASD.  Five  prototype  sets  of  foe  three  MCM  designs  were  completed  in 
September  1993.  Tliese  modules  are  currently  in  radiation  testing.  No 
production  quantities  are  planned. 

The  coiKurrent  engineering  practices  served  foe  project  weU.  The  main  design 
problems  encoimtered  were  foe  lack  of  sufficient  gate  coimt  capacity  for  foe 
simulator,  foe  lack  of  modeb  to  support  foe  standard  parts,  and  non-standard 
design  rules  for  substrate  design  and  process. 

Comanche  MCMs 

The  digital  portions  of  foe  Comanche  ASIC  designs  were  captured  using  foe 
VHSIC  Hardware  Description  Language  (VHDL),  and  converted  to  foe  applica¬ 
ble  Tedmology  Libraries  for  foe  selected  ASIC  supplier  (VLSI  Technology,  Inc.). 
The  EDIF  netlist  format  was  used  to  port  foe  design  between  various  tools.  The 
Valid  Logic  "RapidSim"  tool  on  foe  Cadence  design  platform  was  used  for  tim¬ 
ing  simulations,  with  validated  timing  modeb  provided  by  foe  ASIC  supplier. 
The  LMSI  Hardware  Modeler  tool  set  was  used  to  carry  foe  digital  ASICs  up  to 
foe  multi-chip  simulation  level. 

MCM  byout  was  performed  using  foe  Allegro  MCM  tool  from  Valid  Logic. 
Unfortunately,  due  to  schedule  pressures,  foe  layout  effort  was  started  before  foe 
design  rules  were  negotiated  with  foe  module  supplier,  CIS.  These  rules  started 
as  a  loose  set  of  verbal  rules,  and  foen  later  matured  into  formal  constraints 
which  were  incorporated  into  foe  Allegro  toob.  This  allowed  a  parallel  design 
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effort  and  a  faster  turn  time,  but  also  caused  some  wasted  effort  because  of 
minor  layout  changes  which  were  driven  by  Design  Rule  Q\ecks  (DRCs)  being 
run  late  in  the  design  cycle.  The  lesson  learned  here  is  to  get  the  rules  for  the 
prospective  MCM  suppliers  into  a  technology'  database  in  the  beginning  of  the 
design  process. 

The  Allegro  tools  provided  a  netlist  output  in  a  format  consistent  with  the  MCM 
supplier,  CTS.  This  handoff  was  accomplished  smoothly  for  the  Comanche 
Pro^am.  Prototype  MCMs  were  success^y  produced  in  July  1993.  The  first 
production  modttles  are  now  neanng  completion. 

F-22MCMS 

The  digital  aspects  of  the  F-22  MCM  deagns  used  the  same  methodology  and 
toolset  as  the  Comanche  MCM  designs.  The  results  were  also  similar.  The  tools 
provided  a  good  environment  for  tte  use  of  concurrent  engineering  practices. 

The  analog  aspects  of  the  F-22  MCM  designs  have  been  piecemeal,  as  compared 
to  the  digital  designs.  The  Cadence  design  platform  provides  an  "Aruilog 
Workbench"  tool,  but  it  is  not  directly  linked  to  the  Allegro  layout  tool.  The 
result  is  that  the  constraint  driven  design  approach  used  for  purely  digital 
designs  cannot  be  incorporated  for  mixed  si^ud  designs.  There  are  no  tools 
whi^  can  adequately  extract  die  required  geometric  i^ormation  from  the  lay* 
out  database  to  support  correct  simulation  of  transmission  line  properties,  noise, 
crosstalk  and  other  parasitic  effects  introduced  by  the  MCM  substrate. 

Our  designers  have  been  able  to  use  the  Greenfield  Analysis  tool  to  extract  dr* 
cuit  models  from  the  MCM  netlist,  but  the  result  is  a  simplified  lumped 
parameter  model.  This  lunqied  parameter  model  is  sufficient  for  quantify^g 
switching  noise  from  the  digitai  devices,  and  is  good  for  determining  the 
requirements  for  power  and  ground  decoupling  capacitors  for  each  digital  ASIC. 
The  Greenfield  tool  has  also  been  used  to  analyze  the  effects  of  high  numbers  of 
simultaneously  switching  outputs  between  large  digital  ASIC.  However,  the 
tool  has  proved  inefrective  for  analyzing  high  frequency  analog  performance. 

The  result  of  die  lack  of  synergy  of  the  analog  tools  has  been  a  reliance  on  man¬ 
ual  calculations;  and  on  the  experience  and  intuition  of  the  analog  designers. 
The  "Harris  GASD  Fastrack"  tools  did  prove  adequate  for  modeling  the  perform¬ 
ance  of  the  analog  ASICs  supplied  by  Harris  Se^conductor.  The  problem  was 
in  developing  good  models  for  the  effects  of  die  passive  elements  of  the 
substrate  circuit^,  and  how  the  analog  chips  interacted  with  the  substrate  and 
with  each  other.  Tools  were  not  available  which  could  provide  the  3  dimen¬ 
sional  analyses  required  for  MCM  level  simulations.  This  lack  of  tools  made  the 
analysis  of  signal  noise  difficult  and  tedious. 

Despite  the  lack  of  synergistic  analog  tools,  die  application  of  concurrent  engi¬ 
neering  mediodology  did  prove  effective  for  the  F-22  mixed  signal  MCMs. 
GASD  was  able  to  good  information  from  the  MCM  supplier  (CTS)  on  the 
passive  circuit  characteristics  of  interest,  such  as  the  dielectric  constant,  the 
electro-magnetic  properties  of  the  MCM  substrates,  and  the  manufacturing  con¬ 
straints  (line  widdi,  pitch,  etc).  The  primary  problem  was  that  after  this 
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infonnation  was  collected,  dtere  were  no  analog  tools  to  fully  exploit  this 
information. 

After  dte  mixed  signal  MCM  layout  was  c(»npleted,  the  Allegro  tools  provided  a 
direct  nedist  output  for  CTS,  tlw  MCM  supplier.  As  with  Comanche,  this  hand- 
off  was  accon^lished  smoothly  for  the  F-22  Program.  MCM  prototype  modules 
were  successfully  delivered  in  F^nuuy  1993. 

MCM  Test  Data  Generation 

The  luurative  which  follows  provides  a  background  discussion  of  the  Design- 
for>Test  (DFT)  features  used  by  Harris  GASD.  This  discussion  includes 
desaiptions  of  dte  various  implementations  used  for  different  Harris  GASD 
programs. 

Design  for  Testability  (DFT) 

Harris  GASD  has  developed  a  Design-for-Test  (DFT)  methodology  for  the  digital 
logic  in  complex  MCMs,  which  is  based  on  reusable  BIT/BIST  scan  test  modules. 
In  its  full  implementation,  each  iiulividual  digital  ASIC  chip  incorporates 
Built-in-Test  (BIT)  internal  scan  logic  for  all  scarmable  register  elements  (such  as 
flip  flops),  and  bourulary  scan  to  control  the  ASIC  I/O  signal  pms.  This  design- 
for-test  methodology  is  modular.  Each  program  considers  dieir  own  need  and 
selects  either  a  complete  or  a  partial  implementation  to  achieve  the  testability 
level  required  for  a  given  application. 

Each  ASIC  design  usually  includes  logic  for  an  "Qn-Chip-Monitor"  (OCM), 
which  is  a  control  port  used  to  load  up  to  scan  paths  to  their  initial  states,  control 
device  testing  sequences,  and  read  back  the  restiltant  scan  states. 

At  least  one  ASIC  device  per  MCM  usually  incorporates  an  "On-Board-Monitor " 
(OBM)  which  is  a  semi-autonomous  test  controller.  This  OBM  device  communi¬ 
cates  Mdth  dte  OCM  ports  via  a  shared  ETM-Bus  intenuil  to  the  MCM.  The  OBM 
has  die  capability  to  control  Built-in-Self-Test  (BIST)  sequences  for  each  of  the 
ASIC  devices  with  an  OCM  port  The  BIST  controller  in  the  OBM  uses  Linear 
Feedback  Shift  Register  (LFSR)  logic  to  generate  pseudo-random  scan  patterns, 
and  cmxqiares  die  final  results  to  a  known  good  test  signature.  This  OBM  device 
communicates  with  the  world  outside  the  MCM  via  a  TM-Bus  which  is  compat¬ 
ible  widi  DoD  JTAGs  and  IEEE  1149  standards. 

This  mediod  allows  very  high  structural  fault  coverage  of  all  the  digital  logic  and 
electromechanical  interconnects  in  an  MCM  to  be  accomplished  by  simply 
issuing  a  f^  simple  commands  over  the  JIAGs  bus  to  the  OBM,  and  then 
giving  the  OBM  the  required  number  of  clocks  to  complete  a  given  BIST 
sequence  (usually  on  die  order  of  1  to  10  million  clocks).  The  combination  of  a 
master  OBM  and  several  slave  OCMs  allows  a  complete  BIT  and  BIST  solution 
without  excessive  overhead.  Most  of  oiur  designs  realize  greater  than  95  percent 
detecticm  of  ”stuck-at"  faults  with  less  dian  10  percent  total  circuit  overhead  for 
the  internal  scan,  boundary  scan  and  OBM/OCM  logic. 

The  OBM/OCM  provides  a  unified  structural  test  methodology  which  can  be 
exploited  first  at  ^e  die  level,  and  then  used  again  for  MCM  level  testing,  again 
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at  ttte  PWB  levd,  and  be  finally  used  to  support  system  level  diagnostics.  This 
structural  testing  is  necessary  ^t  does  not  fully  cover  all  the  test  requirements. 
What  structural  testing  does  is  assure  diat  dtere  are  no  point  defects  caused  by 
errors  in  the  MCM  substrate,  die  MCM  manufacturing  process,  or  by  latent 
defects  in  die  integrated  circuits.  B^vioral  and  functitmal  testing  must  also  be 
perfumed  to  ensure  the  reliability  of  the  final  product. 

The  purpose  of  functional  testing  is  to  validate  diat  the  MCM  can  correcdy  per¬ 
form  aU  of  its  intended  state  machine  functions  in  its  target  application. 
Bdiavionl  testing  establishes  diat  die  MCM  functions  correcdy  for  all  specified 
conditions.  This  includes  factors  such  as  timing  margins  and  voltage  noise 
margins  for  signals,  power  supply  levels  and  the  m^ule  temperature. 

An  in^iortant  part  of  die  design  process  is  deciding  how  much  testing  rigor  to 
impose  at  the  die  level  versus  d%  module  level.  The  cost  of  rework  versus  the 
cost  of  die  level  testing  is  one  part  of  this  tradeofi.  Another  concern  it  that  the 
MCM  level  testing  cannot  establish  how  much  timing  and  voltage  margin  there 
is  for  chip  to  chip  interconnects  after  die  MCM  is  assembled.  For  both  of  these 
reasons,  GASD  has  made  a  significant  effort  to  develop  “at-speed"  testing  tech¬ 
niques  for  use  at  die  wafer  and  die  level.  Our  current  wafer  probe  capability  can 
support  speeds  up  to  600  MHz  for  a  limited  munber  of  pins  (up  to  32),  and  100 
MHz  for  the  remaining  pins  (practical  limit  is  about  300). 

After  die  MCM  is  assembled;  structural,  functional  and  behavioral  and  must  be 
accomplished  at  the  MCM  level.  The  structural  testing  relies  on  the  OBM/OCM 
architecture  described  earlier.  Functional  and  behavioral  testing  often  require  a 
piecemeal  approach.  Digital  testing  requires  MCM  level  functional  and  timing 
simulations,  which  are  translated  for  use  by  die  tester.  The  testing  of  analog  I/O 
pins  and  Fiber-Optic  interfaces  may  require  the  careful  insertion  of  either  analog 
multiplexers  or  loop-back  structures  to  aUow  analog  functions  to  be  isolated  and 
tested  at  the  MCM  level.  In  die  concurrent  engineering  model,  die  test  engineers 
are  part  of  the  MCM  design  team,  so  diat  such  concerns  are  not  neglected.  This 
con^ination  of  built  in  test  features  has  allowed  Harris  GASD  to  deliver  reliable 
product  for  a  variety  of  military  applications. 

Brilliant  Eyes  MCMs 

The  success  realized  by  GASD  in  the  use  of  concurrent  engineering  for  design  to 
manufecturing  can  be  sustained  dirough  to  test  generation,  for  purely  digital 
designs.  On  the  "Brilliant  Eyes"  program,  we  were  able  to  translate  a  Boolean 
representation  of  the  memory  modules  into  a  "C"  code  model,  and  then  write  "C" 
procedures  which  generated  exhaustive  test  patterns.  Because  memory  modules 
designs  use  tighdy  structured  logic,  module  level  test  generation  is  relatively 
trivial,  but  it  does  neverdieless  illustrate  how  concurrent  engineering  applies  to 
test  generation.  The  timing  and  format  limitations  of  the  target  test  system,  in 
the  case  an  HP82(X)0,  were  formally  captured  in  technical  narrative  and  given  to 
design  team.  The  generation  of  die  "C"  code  was  performed  as  a  joint  efiort  by 
die  design  engineers  and  test  engineers.  The  Valid  Logic  simulation  tools  were 
used  to  establish  that  the  Boolean  model  of  the  module  stayed  closely  coupled 
widi  the  electrical  design.  This  allowed  the  test  generation  effort,  which  was 
driven  fi-om  die  same  Boolean  model,  to  proceed  in  parallel  with  the  detailed 
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MCM  design  and  layout  effort.  The  output  of  the  "C"  model  was  then  translated 
via  TSSI  tools  into  die  format  required  for  die  HP82000.  The  resulting  MCM 
level  test  patterns  have  been  verified  on  the  Proof'Of>E)esign  (POD)  units 
delivered  by  die  module  supplier,  CTS. 

Comanche  MCMs 

The  digital  aspects  of  MCM  level  testing  for  the  two  Comanche  Mixed  Signal 
MCMs  were  managed  using  die  SYNOPSYS  tool.  SYNOPSYS  was  used  at  the 
VHDL  level  to  ixqect  scan  padis  for  both  internal  scan  of  the  digital  ASICs,  and 
boundary  scan  to  test  die  chip  to  chip  int^connects.  The  MCM  and  ASIC 
designs  fot  Comanche  used  a  partial  implementation  of  Built-in-Test  (BIT)  which 
included  internal  chip  level  scan  plus  boundary  scan  only. 

The  TESTSCAN  tool  was  used  to  die  structural  test  vectors  for  validation  of  the 
assembled  MCM.  Functional  and  behavioral  test  vectors  were  generated  using 
the  LMSl  tools.  These  various  test  vector  pattern  sets  were  translated  by  the  TSSI 
toob  for  the  target  test  system.  Testing  was  acconqilished  on  the  transmitter  and 
receiver  circuitry  using  loop-back  test  techniques. 

F-22MCMS 

The  testing  approach  used  for  the  F-22  MCMs  was  similar  to  that  used  for 
Comanche.  The  main  difference  b  that  a  full  implementation  of  OCM  and  OBM 
structures  was  used.  Thb  allowed  full  Built-in-Self-Test  (BIST)  to  be  accom¬ 
plished  at  the  MCM  level,  in  contrast  to  the  BIT  mefoodology  used  for 
Comanche.  Thb  allowed  98  percent  coverage  of  stuck  at  faulte  at  the  die  level  to 
be  accoirqplbhed  during  MCM  level  testing.  The  BTT/BIST  approach  also 
allowed  100%  coverage  of  the  chip  to  chip  interconnecb  on  the  substrate,  and 
100%  for  the  signal  paths  from  the  MCM  I/O  pins  back  to  the  chips.  The  combi¬ 
nation  of  BIT  and  BIST  also  reduced  d\e  required  number  of  test  vector  to 
reduced  from  about  8  million  down  to  about  2  million,  while  still  achieving  98% 
fault  coverage. 

Next  Assembly  Level  for  MCMs 

The  printed  wiring  boards  (PWBs)  used  on  the  F-22  and  Comanche  Programs 
were  designed  using  the  Allegro  layout  tool.  During  board  design,  thb  tool  had 
serious  problems  handling  tiiamal  vias  and  buried  dectrical  vias.  There  was  no 
provbion  for  identifying  vias  placed  only  as  thermal  conduib,  and  the  layout 
system  would  attempt  to  remove  them  be»use  they  were  not  related  to  tiie  elec¬ 
trical  netlbt.  A  patch  was  added  to  the  software  to  identify  the  thermal  vias  as 
power  vias,  but  tius  caused  problems  with  the  power  simulation.  These 
nuisance  factors  made  the  design  process  awkward.  The  toob  for  modeling 
thermal  effecb  wue  not  suHident  to  handle  tite  tiiermal  interface  bom  the  MCM 
to  the  board.  These  calculations  were  required  to  be  performed  numually. 

The  PWB  byout  toob  also  do  not  provide  an  easy  pati\  to  extract  the  information 
needed  to  develop  thermal  modeb  for  power  dissipation,  and  analog  models 
rteeded  for  power  aitd  ground  routing. 
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Anottter  problem  lies  in  ttie  area  of  test  vector  generatimt.  The  multiple  chip 
simulations  supported  on  the  Valid  Logic  platfonn  emphasize  two  aspects  of 
rigorous  testing.  One  aspect  is  worst  case  device  bduivicMr  modeling  to  establish 
timiitg  and  vdtage  margins.  The  other  is  the  generation  of  rigorous  test  patterns 
witii  Itigh  ftiult  coverage  to  rule  out  any  raiuiom  point  defects  and  verify  fuirc- 
tionality.  The  use  of  BIT  and  BIST  via  scan  patii  testing  was  used  to  establish 
good  foult  detection  at  botir  the  die  and  ouxlule  level.  All  of  titese  test 
approadres  assume  that  tire  purpose  of  testing  is  verify  functionality  arrd  timing 
at  actual  system  clock  speeds  with  a  hi^  ^>eed  tester  such  as  tire  1^2000.  The 
problem  ccnxtes  after  a  fault  is  detected. 

This  combirration  of  structural,  fut^onal  aird  bdravioral  tests  are  sufficient  for 
verification  and  screerring,  but  are  rrot  rrecessarily  su^dent  for  isolating  failures 
for  eitirer  module  or  board  level  rework.  At  this  pmnt,  tirere  will  be  rtumy  pos¬ 
sible  fiulure  medranisrtrs  to  be  considered.  The  fiulure  could  be  caused  by  a 
latent  defect  in  tire  MCM  or  PWB,  operrs  or  shorts  irrduced  by  tire  MCM  attach¬ 
ment  to  the  PWB,  a  die  failure  iruluced  by  harrdlirrg  or  temperature  stresses 
during  solder  reflow,  or  a  host  of  otirer  possibilities. 

There  are  really  two  issues  in  tire  area  of  fault  isolation.  First,  the  board  level 
testing  usuaUy  uses  in-drcuit  board  testers  which  are  desigrred  to  use  "guided 
probe"  style  diagnostics.  However,  tire  diagnostic  software  currently  available 
for  in-drcuit  testers  does  not  support  devices  with  tire  complexity  of  these 
MCMs.  The  second  issue  is  the  test  patterns  generated  for  MCM  aird  board  level 
testing.  The  boundary  scan  patterns,  if  deverly  designed,  could  be  organized 
into  a  set  of  small  stand-alone  patterns  which  test  tire  various  levels  of  intercon¬ 
nects  both  inside  and  outside  of  tire  MCM.  Existing  simulation  tools  would 
provide  at  least  limited  support  of  such  diagnostic  patterns.  Future  test  tools 
should  be  upgraded  to  fully  support  fault  isolation  in  addition  to  fault  detection. 

Time  Lines  to  Project  Completion 

The  successful  experience  by  Harris  GASD  programs  using  MCMs  in  tire  use  of 
concurrent  engineering  for  design  to  manufacturing  and  testing  also  carried 
through  to  the  management  of  tire  MCM  production.  The  plan  for  module  level 
production  of  the  MCMs  was  develc^red  using  the  brte^ated  Manufacturing 
Operating  System  (IMOS)  software  tool.  IMOS  was  used  to  mairage  and  track 
tiw  pilot  production  of  tiw  Proof-of-Design  (POD)  modules  by  CTS,  our  MCM 
supplier.  Harris  GASD  procures  all  of  the  ASIC  die  used  for  the  MCM  assem¬ 
blies,  and  delivers  "known  good"  die  to  tire  MCM  suppliers.  The  material 
management  and  part  procurement  activity  is  managed  with  tire  Parts  Control 
aird  Tracking  System  (TCATS)  software  tool.  The  IMOS  and  PCATS  tools  share 
a  ccmrmon  technical  database  witir  the  Cadence  design  environment.  This 
system  has  proven  successful  for  tire  delivery  of  botir  Proof-of-Design  (POD) 
modules  and  production  MCMs. 

Data  Transfer  Requirements 

The  process  of  designing  an  MCM  requires  data  from  many  different  sources. 
This  infonnation  includes  customer  requirements,  performance  and  constraint 
data  from  chip  foundries  and  substrate  suppliers,  and  simulation  results  from 
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loftwaie  toob  outside  of  die  MCM  design  platform.  This  section  offers  an 
overview  of  die  various  aitegories  of  data  whidi  must  be  ported  into  the  MCM 
design  platfonn,  for  use  by  die  various  engirwering  disciplines. 

Mechanical  Design 

•  Siqiplier  Base  Capabilities 

•  DieSize 

•  Die  Footprints 

•  Environmental  requirements 

•  Vendor  design  rules 

•  Thennal  Analysis 

Thomal  Design 

•  Chip  Supplier  data  sheets 

•  Environmental  requirements 

•  Vendor  design  rules 

•  MCM  size,  lead  count,  power 

•  Package  Thermal  Characteristics 

ReliabUity 

•  Chip  Supplier  data  sheets 

•  Environmental  requirements 

•  Vendor  design  rules 

•  MCM  size,  lead  count,  power 

•  Thomal  Analysis 

•  MCM  manufacturers  historical  data 

Electrical  Design 

•  Functional  specification 

•  Simulation  data 

•  I/O  numbers 

•  Electrical  guide  lines 

•  Nedist 

•  Vendor  design  rules 

•  Gate  driver/receiver  models 

•  Chip  spedficaticms  and  modds 

Layout  Design 

•  Chip  specifications  and  models 
r  Critical  signals 

•  Layout  constraints 

•  DieSize 
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•  Die  Footprints 

•  MCM  aze,  lead  ccHint  power 

•  Electrical  adiematic 

•  Nedi&t 

•  Vendor  design  rtiks 

•  Gate  dbiver/ieoeiver  modds 

•  Thennal  Analysis 

MCM  Manolactaver 

•  Electrical  adtematic 
«  design  database 

•  Mami^Kturing  procedures 

•  plots  and  drill  tape 

•  partsUsts 

•  documentation 

•  testfixturcs 

•  testvedors 

•  test  qwc  atul  procedure 

Mannlactaring  Sjrstcms 

•  Electrical  adierrutic 

•  design  database 

•  parts  lists 

•  documcittati<m(  drawit^,  plots) 

•  testfixtures 

•  Manufacturing  procedures 

Current  Process  Problems 

Ibe  following  narratives  and  tables  discuss  problems,  causes  and  "should  be" 
sdutioiu  for  issued  encountered  in  our  MCM  design  e}q>eriences. 

Ability  to  Perform  Simulations 

MCMs  sometiines  use  parts  iK>t  designed  at  Harris  GASD  (off  the  shelf  die). 
There  are  rarely  good  simulation  models  available  for  diese  off  die  shelf  die. 
This  leaves  die  designer  widi  diree  choices,  eidier  to  write  a  new  software  model 
for  simulation,  to  use  a  hardware  modeler,  or  to  forgo  simulation. 

We  can  easily  simulate  ASICs,  but  we  cannot  easily  simulate  MCMs.  MCMs 
may  have  mixed  technology  designs  (e.g.,  CMOS,  ECL,  TTL,  GaAS).  Current 
simulators  have  a  hard  time  handling  mixed  technology  designs,  primarily 
because  of  die  lack  of  ccdierent  libraries.  A  designer  may  have  access  to  a  CMOS 
library  and  an  ECL  library,  but  die  two  libraries  won't  play  togedier  unless  both 
libraries  use  simulation  parameters  in  die  same  way. 
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MCMs,  like  die  F>22  modules,  may  have  mixed  signal  designs  (digital  and  ana¬ 
log).  Mixed  signal  simulators  do  not  exist,  and  simvdaticms  can  not  take  into 
accotmt  the  effects  of  analog  signals  cm  digital  data  and  visa  versa.  Typically 
there  simulations  are  d<»ie  separately  and  die  results  manually  integrated. 

MCMs  have  a  higher  total  gate  count  dian  ASICs  because  they  use  ASICs  as 
building  blocks.  Emulation  time  is  usually  proportiorud  to  gate  coimt,  so  MCMs 
sillily  take  longer  to  simulate  dum  ASICs. 

MCM  simulations  are  needed  not  only  to  prove  out  designs  but  more  impor- 
tandy  to  generate  behavioral  and  fun^onal  test  vectors.  An  overview  of  die 
typi(^  multi-technology  MCM  behavioral  and  functional  test  vector  generation 
is  shown  in  Figure  4.13.  A  "should  be"  solution  with  a  single  simulation  enviro¬ 
nment  is  shown  in  Figure  4.14. 


Figure  13  Multi-Technology  MCM  Simulations  (As  Is) 


These  and  other  MCM  simulation  problems  are  summarized  with  the  "cause" 
and  the  "should  be"  in  Table  4.4. 
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Figure  4.14  Multi-technology  MCM  Simulations  (Should  be) 
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PROCESS  PROBLEMS. 

Ability  to  Perform  MCM  Sim 

ulations 

ITEM 

PROBLEM 

CAUSE 

SHOULD  BE 

Gate  Model 
Library 
from  Different 
Suppliers 

Incompatibility  between 
suppliers  models. 

Unable  to  get  timing 
mformation  between  ASICs 
from  different  suppliers. 

Heterogeneous  Library 
Models  in  one  simulation 
environment. 

Analog 

Siftpals 

Lumped  parameter 
models. 

Simulations  lack  sufficient 
accuracy. 

Need  distributed 
parameter  models. 

Mixed  Signal 
MCM's 

Incompatible  tool  for 
digital  and  analog 
simulations. 

Tool  sets  do  not  handle 
mixed  analog/digital. 

Compatible  tool  sets  that 
will  handle  analog  and 
digital  ASICs. 

Tool  Interfaces 

Incompatibility  between 
high  level  design 
languages  and 
simulators. 

Different  models  are  used 
by  high  level  tools  versus 
simulator  tools. 

Need  to  provide  better 
interfaces  between  tools. 

Multiple  Asic 
MCM’s 

Tools  cannot  simulate 
manv  Asics. 

Simulators  can't  handle 
MCM’s  with  many  Asics. 

Tools  with  multi-chip 
simulation  capability. 

Model 

Hierarchy 

Level 

Caimot  perform 
multiple  chip 
simulation  with 
different  ASICs  and 
standard  logic  devices 
represented  with 
different  model  types. 

Each  simulator  is  focused 
on  its  own  preferred  model 
type  (gate  level  model, 
VHDL,  behavioral  model, 
etc.),  and  models  must  be 
translated. 

Need  a  true  multi-level 
hierarchy  simulation  tool 
which  does  not  require 
traiulations  between 
model  styles. 

Worst  Case 
Temperature 
Analysis  of 
mixed 

technologies. 

Cannot  perform  true 
worst  case  temperature 
analysis  of  mixed 
CMOS/ECL/GaAs. 

Simulators  rely  on  worst 
case  comers  approach, 
which  does  not  properly 
model  how  each 
technology  really  changes 
over  temperature. 

Need  simulators 
designed  for  mixed 
technologies,  which  can 
exploit  temperature 
perfonx\ance  models  for 
the  various  technologies. 
Also  need  standardized 
model  format  for 
entering  this  information 
into  tecFmology 
databases. 

Hardware 

Accelerators 

Models  for  different 
hardware  accelerators 
not  compatible  (for 
example  IKOS  versus 
ZYCAD). 

Models  are  developed  by 
silicon  suppliers  for  each 
technology  for  a  particular 
target  accelerator. 

Standardized  model 
format  for  hardware 
accelerators,  and  set  of 
translation  tools  for  each 
accelerator  to /from  the 
standard  format. 

Table  4.4  Ability  to  Perform  MCM  Simulations 
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Design  for  Testability  (DFD 

The  software  tools  should  automatically  handle  insertion  of  JTAG  interface  to 
MCMs. 

The  current  reality  is  diat  inccm^lete,  improperly  fbnruitted,  or  irurorrect  data  is 
handed  off  between  Design  and  Test,  mostly  because  no  good  definition  exists  of 
what  the  hand-oif  package  should  be.  The  result  is  the  Designer  and  the  Test 
Engineer  must  bodi  spend  a  great  deal  of  time  iterating  on  dw  test  data  until  the 
test  program  is  complete.  Figure  4.15  illustrates  the  difficulty  of  using  multiple 
simulation  tools  to  generate  die  MCM  test  programs.  Figure  4.16  shows  an 
improved  environment  with  additicxial  tools  to  ease  die  translaticm  effort. 

An  overview  of  the  design  for  testability  (DFT)  problems  are  summarized  with 
die  "as  is”  and  die  "should  be"  in  Table  45. 


Figure  4.15  Design  far  Testability  and  Test  Vector  Generation  (As  Is) 
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Figure  4.16.  Design  for  Testabilihf  and  Test  Vector  Generation  (Should  be) 
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PROCESS  PROBLEMS,  Design  for  TestabiUty  (DFT) 


ITEM 

PROBLEM 

CAUSE 

SHOULD  BE 

Analog  and 
Mixed  Signal 
Testing 

Design  for  Test  tools 
neglect  analog 
behavior,  emphasize 
structvtral  testing  of 
digital  functions. 

Difficult  to  describe 
aiudog  behavior,  lack  of 
standards. 

Simulation  tools  which  can 
describe  MCM  level  analog 
behavior  in  a  form  compatible 
with  analog  test  equipment. 

Diagnostic 

Testing 

Test  patterns  difficult 
to  use  for  fault 
isolation  of  bad  MCM, 
to  support  rework. 

Structural  test  tools  such 
as  TESTSCAN  emphasize 
total  fault  coverage,  but 
ignore  diagnostics  and 
fault  isolation. 

Tool  which  supports  a  multi- 
segmented  approach:  a  set  of 
independent  test  patterns  to 
test  each  chip  to  chip  and  chip 
to  module  I/O  pin 
interconnect  path.  Also  need 
real-time  diagnostic  test 
software  (guided  probe) 
which  can  operate  at  MCM 
level  of  complexity 

Acceptance 

Testing 

Test  patterns  to  large 
for  acceptance  testing 
(many  millions  of  test 
vectors). 

Structural  test  tools  such 
as  TESTSCAN  emphasize 
total  fault  coverage  for 
each  ASIC,  plus  the  entire 
MCM  (millions  of 
vectors).  Behavioral  and 
functional  testing  is 
exhaustive  (many  more 
millions  of  vectors). 

Tool  which  generates  a 
limited  set  of  structural, 
behavioral  and  functional  test 
patterns;  based  on 
compromise  between  cost  of 
testing  and  level  of  testing 
rigor  required. 

Proof-of- 
Design  (POD) 
Testing 

Limited  by  concerns 
for  cost  of  acceptance 
testing. 

Tools  such  as  TESTSCAN 
cannot  distinguish 
between  various  levels  of 
required  testing  rigor. 

Tool  which  can  generate 
limited  diagnostic  and 
acceptance  testing  as 
described  above,  and  then 
"pull  out  aJl  the  stops"  and 
generate  a  set  of  many  of 
millions  of  vectors  for  Proof- 
of-Design  (POD). 

Bviilt-in-Self- 
Test  (BIST) 

Existing  simulators 
cannot  predict 
"signature"  for  BIST 
based  on  LFSR  and 
mtemal  SCAN  paths. 
"Signature"  is 
unknown  until  ASIC  or 
MCM  level  testing  is 
completed. 

Software  caimot  handle 
large  number  of 
calculatior\s  needed  to 
calculate  "signature" 
based  on  LFSR  and 
internal  SCAN  paths. 

Better  simulator  software, 
which  can  create  a 
compressed  Boolean  model  of 
BIST  circuitry  and  calculate 
the  "signature". 

Table  4.6.  Design  for  Testability  (DFT) 
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Automatic  Test  Vector  Generation 


The  current  reality  is  that  iiKon^lete,  improperly  formatted,  or  incorrect  data  is 
handed  off  between  Design  and  Test,  mostly  becatise  no  good  definition  exists  of 
what  die  handotf  package  should  be.  The  result  is  that  Design  and  Test  spend  a 
great  deal  of  time  iterating  on  die  test  data  imtil  the  test  program  is  complete. 
The  next  generation  of  tools  should  support  functional  and  behavioral  simula¬ 
tions  constrained  by  the  limitations  of  the  tester  hardware.  Currendy,  these 
problems  are  often  detected  by  the  tester  translation  software,  such  as  T^I,  after 
die  simulations  have  been  completed.  Some  of  diese  test  vector  generation  are 
summarized  in  Table  4.7. 

The  tools  should  also  allow  the  generation  of  different  groups  of  test  vectors  for 
acceptance  and  fault  coverage  testing  versus  diagnostic  and  fault  isolation  test¬ 
ing.  The  existing  combinaticm  of  fun^onal,  behavioral  and  structural  patterns  is 
adequate  for  verifying  that  a  module  has  been  assembled  with  no  manufacturing 
defects  at  chip  or  MCM  level.  Tools  are  needed  which  facilitate  the  diagnostic 
and  fault  isolation  tests  required  to  support  repair  and  rework  of  a  bad  MCM. 

The  generation  of  functional  vectors  is  currendy  compromise  between  cost  of 
test  and  sufficient  testing  rigor.  Exhaustive  simulations  are  often  needed  to 
address  specific  aspects  of  MCM  performance.  The  result  is  a  very  expensive 
test  program  with  many  millicms  of  test  vectors.  Future  simulation  tools  should 
support  limited  subsets  of  functional  tests,  to  control  the  costs  of  acceptance 
testing.  Clever  use  of  BIT/BIST  design  can  cover  the  risk  that  die  were  damaged 
durii^  MCM  assembly,  without  repeated  all  the  exhaustive  testing  for  each 
MCM.  The  exhaustive  testing  could  then  be  limited  to  Proof-of-Design  testing, 
with  significant  cost  reduction. 

Without  better  linkage  to  tester  specific  parameters  such  as  vector  timing,  strob¬ 
ing  and  edge  placement,  the  designer  cannot  know  if  these  parameters  are 
suffidendy  covered  in  the  functior  !  testing.  This  is  an  important  issue  to  the 
generation  of  test  vectors  for  performance  verification  and  Proof-of-Design 
testing.  Future  simulation  toob  should  be  better  coupled  to  the  target  tester  to 
dose  the  loop  on  these  issues.  For  example,  the  designer  may  be  concerned  with 
checking  the  MCM  circuit  design  for  layout  induct  noise  which  could  cause 
functior^  errors.  A  provbion  to  "back-armotate"  the  actual  timing  of  the  tester 
could  be  used  to  validate  die  intended  purpose  of  specific  test  vectors  pattern 
sete. 
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PROCESS  PROBl 

.EMS,  Automatic  Test  Vector  G 

eneration 

ITEM 

PROBLEM 

CAUSE 

SHOULD  BE 

Behavioral 

Testing 

Simulated  timing 
environment  exceeds 
ability  of  tester  hardware. 
Simulation  not  coupled 
to  target  test  systems. 

Tester  hardware  has 
limitations  on  asynchronous 
behaviors,  high  data  or  clock 
rates,  data  waveform 
formats,  etc.  Simulation 
tools  have  no  provisions  to 
eitforce  timing  rules  based 
on  tester  linutatiorts. 

Tools  should  have  features 
which  enforce  constraints  for 
those  simulations  which  are 
performed  for  test  generation. 
Need  ability  to  distinguish 
design  only  simulations  versus 
those  intended  for  test  vector 
generation. 

Functional 

Testing 

Test  patterns  too  large  for 
cost  efrective  acceptance 
testing  at  MCM  level. 
Problem  gets  worse  at 
next  level  of  assembly, 
such  as  PWB. 

Simulation  software 
encourages  exhaustive 
testing. 

Tool  which  supports  several 
levels  of  rigor  for  simulation, 
and  allows  generation  of  subset 
sufficient  for  acceptance 
testing. 

Structural 

Testing 

Structural  test  patterns 
not  adequate  for 
diagnostics  and  fault 
isolation  to  facilitate 
rework  of  bad  MCMs. 

No  distinction  between  fault 
coverage  (acceptance  testing) 
versus  fault  isolation 
(diagnostic  testing). 

Tool  which  automates  the 
generation  of  a  set  of 
independent  test  patterns  to 
test  interconnect  paths:  chip  to 
chip,  chip  to  module  I/O  pin, 
etc.  Need  ability  to  couple 
these  patterns  with  real-time 
diagnostic  test  software 
(fniided  probe). 

Table  4.7.  Automatic  Test  Vector  Generation 


Transfer  of  Design  Rules 

The  start  of  the  design  process  involves  evaluation  of  the  system  requirements 
against  the  MCM  supplier's  design  rules.  The  MCM  design  evolves  from  this 
evaluation,  and  it  constrained  by  the  MCM  supplier's  process  design  rules. 
These  limitations  are  often  informal  specifications  in  a  non-standardized  form. 
The  restrictions  are  often  negotiable  in  nature  and  usually  represent  what  is  easi¬ 
est  for  the  supplier  to  produce.  If  the  buyer  can't  live  with  these  limitations, 
compromise  solutions  are  negotiated. 

The  supplier  and  the  MCM  designer  (buyer)  negotiate  design  rules  which  make 
it  possible  to  produce  the  system  requirements  and  at  the  same  time  are  not  too 
yield  restrictive  to  build,  lltese  rules  are  captured  and  formalized.  These  rules 
are  then  distributed  to  the  design  team.  The  dissemination  of  this  infoimation  is 
often  informal.  In  many  cases  there  is  no  centralized  database  to  store  and 
update  this  information. 

Figure  4.17  iUustr^tes  the  difficulty  in  getting  information  from  the  suppliers  for 
use  in  the  design  .  rocess.  Figure  4.18  shows  a  "should  be "  environment  with  the 
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infbnnation  in  a  comnum  database  in  machine  readable  form,  and  with 
standardized  formats.  Table  4.8  summarizes  these  and  other  transfer  of  design 
pn^lems. 


INDICATES 

HARDCOPY 


Figure  1 7.  Transfer  qfMCM  Design  Rules  and  Mechanical  Data  (As  Is) 
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Figure  18.  Trans^  qfMCM  Design  Rtdes  and  Mechmiad  Data 
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CESS  PROBLEMS,  Transfer  of  Design  Rviles 


ITEM 

PROBLEM 

CAUSE 

SHOULD  BE 

Documentation  is  often 
informal. 

No  standardized 
doctimentation  method 

Standardized  data  in 
CAD  Database. 

IMCM  circuit 
parasitics 

Layout  tools  do  not 
include  information  on 
passive  characteristics 
needed  to  calculate 
parasitic  effects. 

Layout  tools  are  exclusively 
constraint  driven  (size,  line 
width,  pitch,  etc.) 

Technology  database  for 
each  MCM  supplier 
should  include  circuit 
characteristics  in 
addition  to  layout 
constraints. 

Table  4.8.  Transfer  of  Design  Rules 


Transfer  of  Mechanical  Data 

The  chip  supplier  has  the  mechanical  specifications  for  each  chip.  The  MCM 
designer  may  select  chips  from  several  different  suppliers  to  design  the  MCM. 
These  different  suppliers  may  have  different  mechanical  data,  in  different  units 
and  in  a  different  forms.  This  means  that  the  data  must  be  translated  and  for¬ 
matted  as  required  by  the  MCM  layout  tools.  This  translating  leads  to  errors  and 
delays,  and  increases  the  risk  of  design  iteratior\s. 

Figure  4.19  illustrates  the  difficulty  in  getting  chip  and  next  level  assembly  data 
into  the  design  process  in  machine  readable  form.  Figiure  4.20  shows  a  "should 
be"  envirorunent  with  the  information  in  a  common  database  in  machine  read¬ 
able  form,  and  with  standardized  formats.  Table  4.9  smnmarizes  the  problems 
of  mechanical  data  transfer. 


PROCESS  PROBLE 

MS,  Transfer  of  Mechanical  C 

>ata 

ITEM 

PROBLEM 

CAUSE 

SHOULD  BE 

Chip 

Data 

Information  is 
available  in  differing 
formats  requiring 
manual  entry,  which 
may  cause  errors  or 
design  delays. 

Different  vendors 
supply  parameters 
dif^ently. 

E>efine  a  standard 
method  to  supply  die 
mechanical 
information. 

Data  for 

Next 

Level  of 
Assembly 

Database  does  not 
include  performance 
information  needed 
for  next  level  of 
assembly  (such  as 
PWBorSEM-E 
module). 

Database  is  MCM 
specific.  Information 
on  external 
characteristics 
restricted  to:  footprint, 
size  and  weight. 

MCM  Database 
should  include  other 
information  needed 
at  next  level,  such  as 
required  soldering 
constraints,  thermal 
factors,  handling,  etc. 

Table  4.9  Transfer  Mechanical  Data 
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Applications  Problems 

The  schematic  capture  tool  relks  on  models  of  the  chip  to  accurately  define  each 
integrated  circuit  This  data  includes  pin  names,  ou^ut  type,  function,  electrical 
parasitics  and  driver  and  receiver  modeb.  This  information  is  often  difficult  to 
obtain  from  the  manufacturer  because  of  it's  prc^rietary  nature.  The  informa¬ 
tion,  if  obtained,  still  nnay  not  be  fomuitted  in  a  standardized  form.  Parameter 
values  may  be  presented  in  different  formats,  which  causes  data  inccnnpatibility 
issues  between  suppliers.  This  has  been  a  common  problem  wid\  MCM  designs. 

The  schematic  capture  tod  ouiy  work  well  for  chip  level  designs;  however,  MCM 
designs  having  several  chips  from  different  manufocturers  ixuiy  have  multiple 
groi;^  rddeiKes  widi  difrerent  naming  conventicms.  The  grounds  may  have 
difrierent  names  but  the  same  voltage  potential.  This  problem  causes  manual 
editing  of  the  netlist  names.  This  added  step  adds  both  time  and  risk  to  the 
MCM  design  process.  A  similar  but  more  serious  problem  is  havirrg  the  same 
ruune  on  different  voltage  potentials.  This  problem  is  much  harder  to  detect 
because  it  requires  rrumual  review  of  the  netlist. 

The  auto  routing  of  an  MCM  rruiy  not  always  be  a  realizable.  The  auto  router  in 
rrumy  cases  can't  handle  the  additicmal  requirements  of  stacked  or  spiral  vias  or 
the  multiple  padstack  defirution.  Often  foe  parameters  necessary  to  setup  foe 
router  are  overwhelming  to  foe  layout  designer.  That  lack  of  understanding  of 
all  foe  parameters  and  how  foey  functicm  may  be  a  major  reason  why  foe 
design  are  still  routed  manually.  The  designer  may  think  it  is  easier  to  route 
manually  than  it  is  to  understand  all  the  parameters.  There  is  also  the  perception 
that  a  highly  constrained  design  is  an  unroutable  design. 

In  foe  recent  past  thermal  vias  were  only  considered  as  part  of  foe  design  if  foey 
are  defined  as  a  part  and  assigned  a  net  ruune.  The  software  usually  attempts  to 
minimize  foe  niunber  of  nets  with  foe  same  potential  not  recognizing  foe  unique 
hmcbon  of  the  thermal  vias.  The  software  must  be  able  to  incorporate  these 
unique  structures  such  as  thermal  vias  into  to  foe  layouts.  Themud  vias  could  be 
handled  to  allow  their  prqp>^  to  be  quantified  into  a  thermal  parameter  data¬ 
base  so  their  thermal  effects  '  d  be  automatically  used  in  foe  placement  and 
layout  of  foe  MCMs. 

Noise  analysis  which  has  been  built  into  foe  layout  software  of  several  manufac¬ 
turers  handles  noise  aiudysis  on  a  net  by  net  basis.  An  module  needs  to  be 
added  to  increase  foat  analysis  for  foe  efrects  of  power  and  grotmd  switching 
tu>ise.  This  software  would  consider  the  effects  of  bypass  capacitors  in  foe  cir¬ 
cuit  and  sheet  resistance  of  the  leads.  An  automated  constraint  system  would 
address  foe  power  and  ground  noise  effects  taking  into  accoimt  foe  switching  of 
the  ofoer  cmnponents  in  the  MCM. 


ARPA  Market  Study  —  Case  Study 


Section  4  •  Page  41 


Figure  4.19  illustrates  the  problems  caused  by  using  a  multitude  of  tools,  on 
different  software  platfbnns,  and  with  incon^atible  formats.  Each  software  tool 
is  selected  because  it  performs  S(»ne  necessary  function  not  performed  by  the 
tods  on  die  baseline  design  platform.  This  environma\t  requires  te^ous 
translations  to  be  performed  to  port  data  between  the  diffnent  tools. 

Figure  4.20  below  illustrates  how  a  concurrent  database  could  solve  this  prob¬ 
lem  if  each  software  tool  could  have  a  standard  link  into  a  shared  database 
whidi  contained  both  toe  design  omstraints  and  the  MCM  design  information. 

These  application  problems  are  siimmarized  in  Table  4.10. 
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PROCESS  PRC 

DBLEMS,  Applications  Prot 

>lems  1 

ITEM 

PROBLEM 

CAUSE 

SHOULD  BE 

Schematic 
Capture- 
Chip  Models 

Chip  signal  model 
not  in  library 

Models  difficult  to 
obtain. 

Have  signal  models  in  chip 
library. 

Schematic 
Capture-Multi- 
Chip  Grounds 

Tool  doesn't  handle 
multiple  grounds 
well. 

Grounds  can't  be  easily 
separated  on  MCM's. 

Tool  should  handle  redefining 
grounds  for  MCM's. 

Router 

Some  manual  routing 

Tool  not  mature. 

Designer  not  comfortable 
with  tool. 

Bei  xr  router  tool.  Standard 
data  lOrmat  so  other  more 
manue  tools  could  be  used. 
Education  of  designers. 

Thermal  Vias 

Layout  tools  cannot 
consider  effects  of 
vias  of  heat  traitsfer. 

Layout  tools  have  no 
provisions  for  other  than 
electrical  drcuitry. 

Need  constraint  driven 
features  of  layout  tools  to 
include  thermal  effects. 

Power/Groimd 

Switching 

Noise 

Analysis  of  power 
and  groimd  routing, 
switching  noise, 
decoupling 
capacitors,  etc.,  is 
te^ous  manual 
effort. 

Greenfield  analysis  and 
other  similar  analog  tools 
are  not  fully  integrated 
into  design  platform. 

MCM  layout  tools  should  be 
coupled  with  analog  tools 
with  automated  constraint 
drive  features  to  address 
power  and  ground  noise 
issues. 

Table  4.10  Applications  Problems 


Desired  MCM  Design  Environment 

The  desired  MCM  design  environment  needs  to  provide  the  way  to  share  tvs’o 
types  of  information:  parts  management  information  and  MCM  design  related 
tools  and  data. 

Figure  4.21  illustrates  how  an  MCM  Concurrent  Database  could  provide  a 
shared  platform  to  provide  the  various  engineering  disciplines  access  to  this 
information  using  a  common  format.  The  management  system  tools  we  are 
using  (PCATS,  APIMS,  and  IMOS)  work  very  well  for  managing  the  parts 
related  data.  These  tools,  which  are  on  our  shared  computer  network 
(LAN/MetroNet/InterNet),  keep  each  menO^er  of  the  concurrent  engineering 
team  well  informed  on  what  parts  have  been  selected,  their  availability,  and 
delivery  status. 

One  additional  system  we  are  in  the  process  of  adding  to  oiu:  data  base  is  the 
Information  Handling  Services  (IHS)  on-line  component  data  base.  This  system 
gives  the  user  immediate  access  to  supplier  data  books,  military  r^pedfications, 
and  other  related  component  data.  Each  of  these  management  system  tools; 
however,  are  isolated  islands  within  thentselves. 
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The  MCM  concurrent  data  base  would  pull  all  of  d^se  tools  together  into  a 
common  design  environment.  This  would  allow  the  data  to  be  passed  among  all 
of  die  management  information  and  design  tools.  This  would  also  provide  all 
members  of  the  design  team  immediate  access  to  all  pertinent  data  and  design 
and  analysis  tools  during  the  MCM  design  implementation  process.  The  MCM 
concurrent  database  would  store  all  MCM  foundry  data  in  a  common  foundry 
design  data  fwmat.  The  chip  data  would  be  in  a  common  die  description  for¬ 
mat  The  rules  for  die  next  level  assembly  would  also  be  stored  in  the  database. 
This  would  allow  die  team  to  have  instant  access  to  the  latest  design  rules  for 
bodi  die  foundry  and  the  system  level  manufacturing. 

On  die  design  tool  side,  the  MCM  ctmcurrent  database  would  be  able  to  pull  in 
system  design  data,  all  available  simulation  tools,  layout  and  analysis  tools,  and 
test  tools.  By  using  die  MCM  concurrent  data  base  die  MCM  designer  would 
only  need  to  enter  the  required  data  once  or  direcdy  import  the  requirements 
from  any  of  die  parts  management  tools.  As  part  of  the  MCM  concurrent  data¬ 
base  a  translator  would  resolve  simulation  incompatibilities  and  differences 
between  library  models.  This  would  allow  the  MCM  design  to  be  simulated 
accurately  and  more  importandy  would  allow  the  behavioral  and  functional  test 
vectors  to  be  generated  without  repeating  the  simulations  to  meet  the  test  system 
rules.  The  MCM  concurrent  database  would  be  able  to  take  advantage  of  the 
best  features  of  any  router  and  any  layout  tool  available  in  the  user's  tool  suite. 
The  MCM  concurrent  database  woidd  also  resolve  the  differences  between 
analysis  toob. 
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Fipire  4.21.  Harris  GASD  MCM  Design  Emmvnment  (Should  he) 


Expected  Improvement  for  Reduced  MCM  Design  Cycle 

In  die  ciirrent  MCM  design  environment,  too  much  time  is  spent  gathering  the 
supplier’s  design  rules  and  translating  this  information  into  a  format  which  is 
compatible  widi  the  software  design  platform.  The  sooner  this  information  is 
available,  the  more  efficient  the  design  process  can  become.  Ideally,  this  infor¬ 
mation  should  be  in  the  MCM  conoirrent  engineering  environment  and 
available  to  all  of  the  engineering  disciplines,  before  the  MCM  design  effort  is 
started. 
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A  prime  example  of  tfus  issue  is  ^e  efforts  required  to  assure  Design- 
for-Testability  (DFT),  aitd  ffte  subsequent  simulation  efforts  required  to  generate 
test  vectors  for  structural  and  behavioral  testing.  The  DFT  constraints  are  a 
mature  part  of  the  MCM  design  process  at  GASD,  and  ff\e  tools  required  to  sup¬ 
port  testability  are  integrated  into  Cadence  design  platform.  The  simulation 
constraints  imposed  by  the  Auttmuted  Test  Eqmpment  (ATE);  however,  are 
delivered  to  the  MCM  design  ei^iiiwers  only  in  narrative  form,  and  are  less 
sharply  defined  than  ffw  geiteral  testability  rtiles.  Tester  oriented  problems  are 
not  detected  until  the  translation  from  simulation  results  into  test  vector  pattern 
sets,  bn  an  ideal  design  environment,  these  tester  rules  would  be  entered  into  the 
MCM  Concurrent  data  engineerii^  aiul  would  be  used  to  constrain  ff\e  design 
of  ffte  simulation  stimuli,  for  those  MCM  simulatitms  which  are  intended  to  be 
used  for  test  vector  generaticm. 

Fewer  Design  Iterations 

Design  iteraticms  are  oftoi  caused  by  a  misimderstanding  of  the  supplier's 
design  constraints  early  in  the  MCM  design  process.  As  the  design  rules  mature, 
formal  Design  Rule  Checks  (DRCs)  are  pi^ormed,  and  violatiom  surface  which 
require  design  iterations  to  correct.  The  MCM  concurrent  engineering  environ¬ 
ment  could  be  used  to  constrain  the  design  process  in  the  early  stages  so  that  the 
risk  of  required  design  iterations  would  be  reduced. 

There  are  other  MCM  design  errors  which  are  caused  my  incomplete  simula¬ 
tions,  or  by  modeling  errors.  The  MCM  concurrent  engineering  environment  is 
not  a  panacea  which  can  prevent  all  such  problems  from  occurring  Neverthe¬ 
less,  the  concurrent  engineering  database  can  ease  the  burden  of  performing 
some  of  the  exhaustive  simtilations,  which  will  allow  a  more  robust  design 
envirotunent. 

Greater  Product  Performance 

Both  chip  foundries  and  substrate  suppliers  tend  to  protect  their  yields  by 
imposing  coiuervative  specifications  for  performance  parameters.  This  conser¬ 
vatism  flows  down  to  the  MCM  designs  which  incorporate  these  chips  and 
substrates.  Potential  system  features  are  sometimes  sacrificed  or  compromised 
because  they  exceed  the  supplier's  specifications  for  the  applied  technologies. 

Tighter  limits  are  often  negotiated  with  the  suppliers,  based  on  either  system 
level  requirements  or  knowledge  learned  during  chip  and  MCM  testing.  These 
tighter  limits  could  be  added  to  the  MCM  concurrent  engineering  envirotunent, 
and  used  to  ease  the  constraints  on  subsequent  design  efforts.  The  availability  of 
realistic  parameter  specifications  in  the  MCM  concurrent  engineering  environ¬ 
ment  will  allow  file  designers  to  be  more  aggressive,  and  produce  MCMs  with 
extended  performance  diaracteristics. 

Reduced  Cost 

There  are  several  reasons  why  the  full  e}q>loitation  of  an  MCM  concurrent  engi¬ 
neering  environment  should  be  expect^  to  reduce  costs.  First,  the  Non- 
Recurring  Engineering  (NRE)  costs  of  the  design  will  be  reduced  because  the 
design  cycle  times  and  the  required  iterations  should  both  be  reduced,  saving 
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manpower  costs.  The  material  costs  associated  with  the  Proof-of-Design  (POD) 
units  will  also  be  reduced  because  of  fewer  design  iterations. 

Second,  die  manufacturing  costs  ^Knild  be  reduced.  The  use  of  an  MCM  con¬ 
current  engineering  environment  should  couple  the  design  more  closely  to 
manufacturing  constraints,  which  should  result  in  a  more  producible  design  and 
better  manufacturing  yields.  Hie  Design-for-Testability  (DPT)  methodology  dis¬ 
cussed  previously  in  Section  will  also  produce  a  benefit  to  the  manufacturing 
effort.  The  intelligent  application  of  diis  DPT  philosophy,  together  with  the 
generation  of  more  efficient  test  vectors  for  both  ^agnostic  and  acceptance  test¬ 
ing,  should  help  to  contain  the  increasingly  high  cost  of  MCM  testing. 

Should  be  Flow 

The  design  flow  already  in  place  at  Plarris  GASD  has  served  us  well  in  the 
design  of  fourteen  MQ^.  Concurrent  Engineering  practices  have  been  used 
wherever  they  have  been  applicable,  and  this  approa^  has  been  successful  on 
five  nujor  military  programs.  This  Concurrent  Engineering  methodology;  how¬ 
ever,  has  been  t^eii  to  the  point  of  diminishing  returns,  given  the  existing 
design  platform.  Purdier  improvements  will  require  the  next  generation  of 
software  tools. 

Should  be  Tools 

The  next  natural  step  in  the  software  tools  for  MCM  design  should  be  the  appli¬ 
cation  of  a  real-time  concurrent  engineering  environment.  Prom  its  initial 
inception,  such  an  environment  will  aid  the  design  process  by  providing  a  con¬ 
sistent  source  of  information  for  all  of  the  engineering  disciplines.  This  will 
eliminate  die  redundant  efiorts  of  different  engineers  collecting  the  same  data, 
but  in  difiering  formats.  If  the  various  engineering  disciplines  make  their 
updates,  additions  and  changes  to  this  common  database  in  "real-time",  then  this 
information  can  be  available  to  other  members  of  the  design  team  instantly. 

As  the  format  standards  for  the  design  information  mature,  suppliers  can  be 
encouraged  to  provide  the  constraints  and  performance  characteristics  for  the 
chips  in  substrates  in  a  form  compatible  with  these  standards.  This  maturation 
of  standard  formats  will  reduce  the  required  translations  between  different 
design  and  simulation  tools. 

As  the  software  design  tools  evolve  and  begin  to  support  true  multiple  technol¬ 
ogy  simulations,  the  MCM  concurrent  engineering  environment  will  provide  a 
single  repository  for  the  various  modeling  information  required  to  perform  these 
MCM  level  simulations. 
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Figure  4.22.  Harris  CASD  Software  Tool  Sets  (Should  be) 


Conclusions 

The  availability  of  an  MCM  concurrent  engineering  environment  has  the  poten¬ 
tial  to  provide  a  number  of  direct  benefits  to  the  MCM  design  process.  Some  of 
these  benefits  would  be  seen  immediately.  Other  benefits  would  be  fully  real¬ 
ized  only  after  improvements  to  the  tool  set  environment. 

This  MCM  concurrent  engineering  environment  would  provide  an  environment 
where  all  of  the  engineering  disciplines  coul^  share  design  related  information 
in  "real-time"  during  the  design  process.  The  MCM  conciurent  engineering 
environment  would  also  provide  a  common  repository  for  the  constraints 
imposed  by  the  various  chip  and  substrate  suppliers. 
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This  improved  design  environment  can  be  expected  to  reduce  design  cycle  times 
and  decrease  the  number  of  required  design  iteratiorxs.  These  improvements 
should  help  to  contain  the  NRE  associated  with  each  MCM  design.  This  envi¬ 
ronment  will  also  help  to  control  the  manufacturing  costs  fox  both  the  MCM  and 
the  next  assembly  level,  by  better  coupling  produdbility  issues  to  the  MCM 
design  process. 

In  addition  to  these  immediate  beitefits,  the  MCM  concurrent  engineering  envi¬ 
ronment  also  provides  a  structure  which  allows  the  expected  features  of  future 
software  tools  to  be  fully  exploited.  It  is  expected  that  software  tools  will  mature 
in  the  area  of  true  multiple  technology  design  and  simulation.  The  MCM  con¬ 
current  engineering  enviroiunent  will  encourage  dte  development  of  such  tools 
in  dte  future,  and  will  allow  the  potential  of  diese  features  to  be  fully  realized. 
The  restilt  will  be  a  more  robust  design  and  simulation  environment,  which  can 
produce  higher  performance  MCMs  while  containing  the  design  and 
manufacturing  costs. 
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Section  5  —  Market  Evaluation 

Overview 

The  purpose  of  the  market  evaluation  is  to  assess  the  needs,  problems,  opinions 
and  expectations  of  those  who  are  currently  participating  in  MCM  design  and 
fabrication  or  who  will  be  doing  so  shortly.  The  questions  used  were  broad  in 
scope  in  order  to  establish  both  the  sentiments  toward  MCMs  and  the  industry 
in  general  as  well  as  more  specific  topics  such  as  the  design  enviroimwnt  that 
might  be  impacted  by  ROSE. 

Questionnaire 

A  set  of  19  multi-part  questiorts  were  drawn  up.  Each  person  was  asked  to 
answer  101  individual  questions.  A  complete  questionnaire  is  provided  in  the 
accon^anying  Appendices.  The  questionnaire  was  designed  to  determine: 

•  If  the  contacts  were  current  or  future  user  of  MCMs 

•  MCM  technologies  being  used  or  considered 

•  The  phases  of  MCM  design  and  fabrication  with  which  they  were  involved 

•  Their  use  of  concurrent  engineering  practices  and  willingness  to  invest  in 
design  systems  that  support  that  paradigm 

•  Important  issues  regarding  MCM  design  environment 

•  Their  collection  of  design  tools 

•  Important  issues  in  design  and  manufacturing  of  MCMs 

•  Important  issues  regarding  data  transfer  and  storage 

•  Opinions  regarding  various  existing  data  transfer  standards 

Gap  Analysis 

For  30  of  the  questions,  ratings  of  importance  and  satisfaction  were  recorded. 

For  instance,  from  Question  #10:  "Please  rate  the  following  issues  relative  to  the 
design  and  manufacturing  of  MCMs”,  an  individual  might  have  responded . 

Importance  Satisfaction 

A.  Design  automation  software  9  6 

Bodi  mqx>rtance  and  satisfaction  ratings  are  valuable  pieces  of  information.  But 
additionaUy,  using  importance  and  satisfaction  scores,  a  third  value  would  be 
calculated  called  the  gap.  For  each  line  of  questioning,  the  gap  represents  a 
measure  of  die  pleasure  or  dissatisfaction  wi^  the  current  situation.  Gaps  can 
be  either  positive  or  negative. 

Positive  gaps  larger  than  1  indicate  a  problem  exists  that  is  worthy  of  attention. 
The  larger  the  gap,  the  greater  the  level  of  dissatisfaction  and  frustration  and  the 
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greater  the  opportimity  to  improve  satisfaction  (and  productivity)  if  the  obsta¬ 
cles  are  removed.  Negative  gaps  greater  than  1  iiidicate  that  the  available 
services  or  solutions  are  more  than  adequate  and  that  improvement  investments 
in  these  areas  might  be  de-emphasized. 

Methods 

Using  the  questionztaire  as  a  guide,  a  professional  telemarketing  group  made  the 
phcme  calls  to  each  of  tl.e  potential  respondents.  After  identifying  themselves  as 
a  representative  of  a  marketing  services  group  collecting  data  for  an  ARPA 
study,  they  established  the  willingness  of  the  contact  to  proceed.  If  they  were 
willing  to  proceed,  about  20  minutes  was  spent  collecting  answers  to  the  pre¬ 
scribed  questicms  and  collecting  any  assodat^  comments. 

Respondents 

A  list  of  60  engineers  and  managers  who  were  believed  to  be  involved  with 
MCMs  either  as  designers  and  end  users  or  fabricators  was  compiled.  Using  this 
list,  a  prof^ional  telemarketing  group  contacted  as  many  individuals  as  possi¬ 
ble  by  phone  and  filled  out  the  survey.  A  total  of  28  individuals  agr^  to 
complete  the  questionnaire. 

The  titles  of  the  individuals  who  responded  and  the  identity  of  their  organiza¬ 
tion  is  listed  in  Figure  w.  Four  of  the  respondents  wished  to  remain  anonymous. 

Statistics 

The  data  collected  during  the  phone  interviews  was  entered  into  a  computer 
data  base  for  statistical  reporting  and  analysis.  A  complete  set  of  sorting  and 
reporting  was  generated  for  each  of  the  groupings  of  "All  respondents",  "Current 
Users"  and  'Tuture  Users". 

The  basic  demographics  of  the  respondents  are  shown  in  the  following  Table  5.1. 


Current 

Future 

MCM  Manufacturer 

6 

1 

MCM  Designer 

15 

6 

TOTALS 

21 

7 

28 

Table  5.1  User  Demographics 

A  complete  set  of  reports  and  statistics  is  provided  in  the  accompanying 
Appen^ces. 
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Critical  Analysis 

Summary 

Witiiin  tile  questionnaire  tiiere  30  questions  that  evaluated  the  respondents' 
0(»nions  about  various  aspects  of  design  and  fabrication.  Each  of  these  items 
were  scored  in  terms  of  importance,  satisfaction,  and  gap  as  explained 
previously. 

Tables  5.2, 53  and  5.4  provide  a  quick  but  representative  sununary  of  tiw  market 
evaluaticm.  They  show  the  five  items  of  greatest  importance,  the  five  items  of 
lowest  satisfaction,  and  tiie  five  items  with  the  largest  gap. 

These  tiuree  tables  indicate  tiuit  data  transfer  and  storage  is  indeed  of  high 
importance,  that  satisfacticm  witii  current  capabilities  is  very  low,  and  tiiat  there 
is  a  large  gap  between  what  people  would  like  to  do  and  are  actually  capable  of 
performing. 


Subject 

Importance 

Satisfaction 

Gap 

Coimt 

l.MCMTest 

9.6 

6.6 

3.0 

14 

2.  Substrate  Fabrication 

9.4 

7.5 

1.9 

10 

3.  Design  Methods 

9.4 

8.0 

1.3 

25 

4.  Access  to  chip  and  component  data 

9.3 

5.2 

4.1 

23 

5.  Data  transfer  standards 

9.2 

6.0 

3.2 

24 

Tabk  5.2:  Top  Five  Importance  Items 


Subject 

Satisfaction 

Importance 

Gap 

Coimt 

1.  Store  MCM  data  in  neutral  tile  format 

4.4 

7.6 

3.3 

20 

2.  Move  design  data 

4.5 

7.8 

3.3 

20 

3.  Bi-directiorud  translation 

4.6 

7.1 

2.5 

20 

4.  Support  of  MCM  foundries  dc  design 
kits 

4.6 

7.5 

2.9 

17 

5.  Design  kit  available  for  CAE 

4.6 

7.1 

2.5 

16 

TaUe  5.3:  Lowest  Five  Sati^ction  Items 
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Subject 

Gap 

Importance 

SatisfacticHi 

Count 

1.  Access  to  chip  data 

■ai 

9.3 

5.2 

23 

2.  Bi-directicmal  translation  of  data 

fBM 

7.8 

4.5 

23 

3.  Neutral  data  storage 

3.3 

7.6 

4.4 

23 

4.  Data  transfer  standards 

3.2 

9.2 

6.0 

24 

5.  Unit  Production  costs 

3.2 

8.4 

5.1 

20 

Table  5A:  Largest  Five  Cep  Item 


Specific  Question  Responses 

The  following  pages  highlight  responses  collected  for  individual  questions  and 
conclusions  that  can  be  drawn. 

MCM  Technologies  -  Question  6  and  8 

The  respondents  indicated  they  were  working  with  all  types  of  MCM 
technologies. 


MCM  Type 

Future  Users 

A  MCM-L:  Laminate 

13 

5 

B.  MCM-C:  Ceramic  Thick  Film 

12 

1 

C.  MCM-C:  LTCC 

13 

2 

D.  MCM-D:  Thin  film  on  siliccm  or  ceramic 

11 

1 

E.MCM-HDI:  Chips  first 

5 

4 

Table  5.5:  MCM  Technologies  -  Question  6  and  8 


Question  10 

Questions  in  section  10  were  designed  to  establish  the  issue  importance  and 
solution  satisfaction  with  various  aspects  of  design  software,  tool  integration, 
testing,  data  transfer  and  chip  data. 

The  numeric  responses  ate  summarized  in  Tables  5.6, 5.7  and  5.8. 

One  tiling  these  charts  demonstrate  is  that  there  is  not  a  substantial  difference 
between  current  and  future  users  of  MCMs.  Therefore,  composite  results  repre¬ 
sent  tile  opinions  of  both  groups  in  a  balanced  fashion. 
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Category 

Count 

Importance 

Satisfactitm 

Gap 

A.  Design  Automation  software 

25 

8.5 

6.9 

1.6 

B.  MCM  tool  Integraticm 

24 

8.3 

6.5 

1.8 

C.  Standards  for  data  transfer  between 
design  and  manufacturing 

24 

9.2 

6.0 

3.2 

D.  Access  to  dtip  and  component  data 

23 

9.3 

5.1 

■Bi 

E.  Knowledge  of  design 
medtoddogies  to 
implement  MCMs 

25 

9.4 

8.0 

.6 

F.  Automated  testing  &  quality 
mediods 

22 

8.7 

6.4 

2.3 

Tabk  S£:  MCM  Issues:  Composite  of  Current  &  Future  Users  •  Question  10 


Category 

Coimt 

Importance 

Satisfaction 

Gap 

A.  Design  Automation  software 

20 

8.5 

6.9 

1.6 

B.  MCM  1  Integration 

20 

8.3 

6.6 

mm 

C.  Standards  for  data  transfer  between 
design  and  manufacturing 

21 

9.2 

6.0 

3.2 

D.  Access  to  chip  and  component  data 

20 

9.3 

5.2 

4.1 

E.  Knowledge  of  design 
methodologies  to 
implement  MCMs 

21 

9.4 

8.0 

1.3 

F.  Automated  testing  &  quality 
methods 

19 

8.6 

6.4 

2.2 

Table  5.7:  MCM  Issues:  Current  Users 
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•  "There  are  no  standards." 

• 

No  standard  for  this  really,  except 

•  Nothing  in  place  yet,  lots  more  to 

for  Gerber. 

be  done. 

• 

Necessary  to  achieve  low  cost  and 

•  Uses  existing  standards  for  other 
product  domains  that  don't  meet 

first  time  success,  and  standards 
are  not  widely  available. 

MCM  needs. 

• 

CAD  vendor  output  incompatible 

•  Vendors  prefer  using  their  own 

with  manufactiuing. 

internal  formats  instead  of 

• 

Are  no  standards  in  the  market 

establishing  standards. 

and  no  one  is  working  hard 

•  Tartidpating  in  ARPA  ASEM  at 

enough  on  them. 

MCC"  to  work  on  improvement 

• 

Not  well  developed  yet. 

for  this. 

• 

Never  as  transparent  as  people 
claim. 
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I 

I  Detigm  Environment  •  Question  11 

Questicm  11  was  targeted  directly  at  data  transfd*  and  storage.  Average  impor- 

Itance  was  moderately  high  but  satisfaction  was  radier  low  resulting  in  Ivge 

gaps.  Surprisingly,  the  re^>ondents  feel  diat  it  was  dqI  important  or  desirable  to 
buy  all  software  from  cme  vendor.  There  tvas  a  stror  mef^ence  that  heterogeneous 

Isafiume  work  together  and  that  data  be  stored  in  non-prt  ^  letary  format. 

Comments  to  questions  llA  and  IID  were  especially  indicative  of  emotions 
where  Ate  gaps  were  3.4  and  33  respectively. 


Phase 

Respoitses 

Importance 

Satisfaction 

Gap 

A.  Bi-directional 
translation 

23 

8.0 

4.6 

B! 

B.  Concurrent  design 

21 

7.0 

5.3 

1.7 

C.  Data  transfer 

23 

7.1 

4.7 

2.5 

D.  Neutral  storage 

23 

7.7 

4.4 

3.3 

E.  Best  application 

24 

7.7 

6.9 

0.8 

F.  Sngle  Vendor 

22 

53 

6.4 

-1.2 

Table  S.9a:  Data  Capability  Assessment  •  Question  11 


Data  transfers  difficult,  i.e. , 
Cadence-to-Mentor. 

No  existing  standard  satisfies  dus 
need. 

Nearly  impossible  to  do  this. 
Vendors  are  too  proprietary. 

No  standard  for  this  capability 
duit  he  is  aware  of. 

CAD  and  CAE  standards  not  firm 
yet  Software  is  unproven. 
Industry  is  heading  right  way, 
most  not  smooth  yet.  Point 
sdution  integration's  is  "not  there 


Lack  of  standards.  CAD/CAE 
vendors  slow  to  adopt  existing 
standards. 

Foundries  need  to  accept  data 
from  many  CAD  systems. 

Not  one  on  market.  Still  needs  to 
be  developed. 

Still  not  fully  developed  yet. 

Will  implement  further  down  the 
road. 

Not  as  transparent  as  people 
claim. 


yet" _ 

Table  5.9b:  Bi-directional  Data  Translation  -  Question  llA  -  Comments 
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Fwmats  not  well-standardized. 
Advent  of  STEP  staiKlard  will 
require  the  delivery  of  STEP  for 
MCM  products. 

Neutral  file  is  not  defined  to  cover 
different  MCM  design  levels.  Will 
be  a  challenge  to  get  vendor 
support  once  diey  are  defined. 
Doesn't  exist  really. 


•  No  real  standard  for  this. 

•  Teduu>logy  is  still  evolving. 

•  Neutral  format,  CAD  system 
independent. 

•  Still  needs  developing. 

•  Not  aware  it  can  be  done. 

•  Will  iizq>lement  later. 

•  Can't  be  done. 


TaUe  5.9c:  MCM  Data  m  Neutral  format  •  Question  IID-  Comments 


Question  12 

Within  section  12  several  questions  were  asked  regarding  the  MCM  design 
environment.  The  numeric  responses  are  summarized  in  Table  5.10a. 


Phase 

Responses 

Importance 

Satisfaction 

Gap 

A.  System  Spedficatioits 

19 

8.2 

6.6 

1.6 

B.  System  Partitioning 

21 

8.0 

5.8 

2.2 

C.  Autorouting 

23 

8.5 

7.2 

1.3 

D.  Packaging  Technology 
selection 

21 

8.4 

6.2 

B 

E.  Design  kits 

21 

7.8 

4.9 

2.9 

F.  Optimization  of 
manufacturinK  data 

19 

8.1 

5.9 

2.2 

Table  5.10a  MCM  Design  Environment  -  Question  12 
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Few  vendors  offer 

It's  just  becoming  available.  "Just 

not  there." 

1^Iot  much  there."  Foundries  just 
beginning  to  biiild  kits. 

Not  nearly  enough 
interconnection,  and  not  enough 
design  kits. 

'Hasn't  goiw  all  too  smooth." 


Not  many  design  kits  available  for 
technolc^. 

Emerging  Technology. 

Don't  have  any  real  design  kits 
yet. 

Very  few  kits  available.  Those  that 
are  available  are  geared  to  specific 
designs. 

Don't  do  it;  what  they  do,  won't 
guarantee.  Cost. _ 


TaUe  5.10b  List  comments  spec^  to  questions  12E  -  Comments 
Concurrent  Engineering  -  Questions  13  and  16 

In  response  to  question  13,  24  interviewees  said  that  they  are  using  Concurrent 
Engineering.  From  question  16  we  assess  the  importance  of  "investing  in  Design 
automation  systems  to  meet  concurrent  engineering  requirements"  was  quite 
high. 


Extremely  Important 

11 

Very  Important 

6 

Important 

6 

Not  Important 

1 

Total 

24 

Using  a  rating  scale  of: 


Extremely  Inq>ortant 

10 

Very  Important 

8 

Inqxirtant 

5 

Not  Important 

1 

Total 

24 

Gives  a  composite  inqx)rtance  of  8.0 
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Tliis  suppcnrts  commentary  coUected  in  response  to  related  lines  of  questioning 
duit  design  autmnatitm  systems  are  very  important  to  success  in  MCM  design 
and  that  investments  in  this  area  are  seen  as  very  beneficial. 

The  general  message  obtained  from  Question  18  on  data  exchange  standards  is 
fiuit  they  are  iu>t  a  very  important  element  of  the  MCM  design  process  aiul  that 
standards  useful  for  MCM  generally  don't  exist. 

While  several  people  condemned  older  standards  like  Gerber  aiul  GDSn,  and 
some  people  are  not  familiar  with  STEP/PDES,  there  xvas  a  rather  favorable  view  of 
the  STEP/PDES  potential. 


Phase 

Coimt 

Importance 

Satisfaction  Gap 

A.cn 

20 

6.8 

4.8 

2.0 

B.  STEP/PDES 

14 

6.4 

4.5 

1.9 

C.IGES 

16 

7.3 

6.5 

0.8 

D.EDIF 

22 

7.7 

5.7 

2.0 

E.IPC-350 

13 

5.5 

4.5 

0.9 

F.  Gerber 

23 

8.0 

7.1 

0.9 

G.  GDSn  stream 

22 

8.0 

7.5 

IDSII 

H.DXF 

21 

7.3 

6.9 

0.5 

Tabu  S.lla:  Data  Exdumge  Standards  •  Question  18 


•  Looks  promising. 

•  Not  familiar  with. 

•  Not  familiar  with. 

•  Not  familiar  with. 

•  "On  right  track." 

•  Not  familiar  with. 

•  Has  right  info,  content,  but  not 

•  Don't  use  these  standards.  Does 

useful  until  vendors  support  it. 

not  support  MCM  now. 

•  Don't  use. 

•  No  standards  yet. 

Tdble  5.11b:  STEP/PDES  -  Comments 
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Section  6  —  Market  Analysis 

MCM  Market  Overview 

The  market  for  MCM  technology  has  now  touched  upon  all  segments  of  the 
electronics  industry. 

The  Defensc/Aeiospace  and  Government  electronics  market  is  using  MCM 
technology  for  its  high-performance  at  a  reduced  size,  wdght  and  power  con- 
suixq>tion.  Govemment-fuiuled  programs  for  defense  and  aerospace  related 
projects  have  stimulated  the  development  of  new  materials  and  new  MCM 
substrate  manvifacturing. 

Computer  systems  are  turning  to  MCMs  for  new  microprocessor  architectures, 
memory  subsystems,  and  wireless  communications  capabilities. 

Consumer  products  apply  low-cost  MCM  technologies  for  hand-held  and 
portable  products. 

Telecommunications  s3rstems  are  pushing  for  greater  levels  of  performance  and 
the  integration  of  coixununicatioits  and  computers. 

Automotive  applications  are  growing  as  the  industry  adds  electronics  to 
provide  new  safety  features,  engine  maiugement,  and  driver  conveniences. 

Each  industry  segment  has  a  broad  range  of  applications  for  MCMs  that  cover 
various  price  and  perforrrumce  points. 

MCM  technology  adds  another  level  of  complexity  to  the  systems  design 
process.  MCM  packaging  influences  the  final  cost,  performance,  and  competi¬ 
tive  positioning  of  a  product;  dwrefore,  systems  design  engineers  must  consider 
the  wide  range  of  choices  early  in  the  design  cycle. 
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Figure  6.1  Anticipated  Usage  cf  Advanced  Packaging  Techniques 

MCM  technology  acceptance  demands  new  design  automation  tools.  Many 

forces  are  driving  the  systems  design  engineer  to  include  MCM  packaging  in  the 

next  generation  product  such  as: 

•  System  interconnect  of  ICs  with  large  I/O  (pin)  counts  of  400  or  more  pins. 

•  Qock  speeds  above  50  MHz  (i.e..  Digital  Equipment  Corporation’s  Alpha 
processor  operates  at  175  MHz). 

•  Mixed  signal  applications  allowing  for  optimal  combination  of  analog  and 
digital  ICs. 

•  Reduction  in  system  size,  power,  and  weight  while  increasing  functionality 
and  the  number  of  active  devices. 
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Figure  €.3  Clock  Speeds  (Leading  Edge) 
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The  MCM  market  is  beii^  held  back  due  to  economic  issues  associated  with 

MCM  design. 

•  MCM  technology  adds  risk  to  schedules  and  costs  as  engineers  learn  how  to 
best  apply  the  new  technologies. 

•  New  design  automation  tools  require  additional  investment  and  those  new 
tools  must  operate  within  the  existing  design  environment. 

•  New  data  types  and  greater  amounts  of  design,  manufacturing,  and  analysis 
data  must  be  shared  among  design  groups  and  their  associated 
applications. 

•  The  cost  of  many  MCM  processes  is  too  hi^  for  price  sensitive  applications 
such  as  consumer  electronics. 

Industry  projections  from  market  surveys  such  as  Dataquest  and  BPA  System 

2000  forecast  that  significant  growth  in  MCM  technology  usage  will  occur  in 

1994  (see  references). 


EDA  environments  must  progress  to  support  these  new  packaging  choices.  At 
the  same  time,  product  life  cydes  are  shrinking.  This  drives  the  ne^  for  concur¬ 
rent  engineering  teams  rrude  up  of  multiple  disdplines  from  engineering  and 
maniifacturing. 
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EDA  Market 


Dataquest  reports  that  1992  and  1993  were  years  of  transition  for  the  EDA  mar¬ 
ket  as  a  whole.  Competitive  pressures  in  die  end-user  environment  forced  a 
highor  level  of  integration  and  system  conq>lexity  with  fewer  people. 

Approximately  140  companies  participate  in  the  EDA  market  according  to 
^taquest  The  total  revenue  fr^  software  licenses  for  199k  was  $1.3  billion 
(hardware  Mlded  another  $1.4  billicm). 

The  end-user  must  select  specific  applications  from  this  large  number  of  niche 
and  broad  line  suppliers  to  create  an  efficient  and  efrective  design  environment. 

The  EDA  industry  and  its  products  are  very  dynamic.  New  design  automation 
tools,  user  environments,  and  omnpanies  are  created  or  disappear  each  year. 
Existing  design  automation  tools  are  continuously,  incrementally  improved 
while  entirely  new  tools  emerge  from  university  research,  government-spon¬ 
sored  programs  and  industry  product  development. 

This  dynamic  environment  has  caused  the  end-user  great  expense  in  the  support 
of  existing  design  databases  and  in  merging  the  best  functions  of  existing  design 
automation  tools  witfi  new  products  as  they  become  available.  Products  that  are 
no  longer  supported  by  a  corrunerdal  EDA  company  must  also  continue  to  oper¬ 
ate  in  tire  overall  design  environment  if  they  continue  to  serve  a  useful  purpose. 

An  MCM  concurrent  engineering  envirorunent,  built  around  an  intematiorud 
standard  such  as  STEP  could  provide  valuable,  cost  saving  glue  among  past, 
present,  and  future  EDA  tools.  Data  can  be  preserved  and  made  accessible  to  the 
end-user  to  reduce  the  time,  effort,  and  money  spent  on  maintaining  that  data. 

The  availability  of  expert  EDA  design  data  management  and  programming 
services  would  provide  the  end-user  ^e  option  of  purchasing  additional  assis¬ 
tance  when  necessary.  And  with  an  open  system  of  the  conciurent  engineering 
envirorunent,  other  third-party  suppliers  of  programming  services  could 
compete  for  and  then  supply  services  to  ti\e  end-user. 

Future  revenue  growth  opportunities  for  EDA  suppliers  will  come  from  new 
software  applications  that  iiiq>rove  productivity  and  reduce  the  cost  of  designing 
electronic  systems.  Products  suggested  by  this  market  survey  are  in  demand  by 
end-users  and  include  the  devdopment  of  advanced  physical  design  tools 
(indudit^  MCMs)  that  iirdude  aiudysis  capabilities,  architectural-level  tools  that 
improve  designer  productivity,  and  an  increased  level  of  services. 

Services  will  indude  integration  and  consulting  services  that  are  targeted  at 
optimizing  tiie  overall  design  environment,  and  support  of  concurrent 
engineering  design  methodologies. 
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Market  Potential 


The  market  for  EDA  software,  indudmg  concurrent  engineering  mvironments, 
software  tods,  and  services  is  illustrated  in  Figure  6.5. 


Figure  6.5  Worldwide  EDA  Software  and  Service  Market  History  and  Forecast 

The  following  areas  are  forecast  to  experience  significant  growth; 

•  Advanced  physical  design  tools  (including  MCMs)  fiuit  include  analysis 
capabilities 

•  Architectural-level  tools  duit  improve  designer  productivity 

•  Services,  Including  integration  and  consulting,  are  targeted  at  optimizing  the 
overall  design  environment,  support  of  concurrent  engineering  design 
methodologies. 

•  Concurrent  engineeru^  environments  and  frameworks. 
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Although  ttte  leading  market  studies  do  not  highlight  the  specific  forecast  in 
these  areas,  the  following  estimates  are  derived  by  comparing  multiple  sources 
of  data  and  interpolatmg  these  numbers. 


Year 

1993 

1994 

1995 

1996 

Concurrent  Engineering 
environments 

$13M 

$28M 

$43M 

$58M 

%of  EDA  market 
revenue 

1% 

2% 

3% 

4% 

MCM  design  software 
applications 

$17M 

$34M 

$52M 

$80M 

%of 

PCB/MCM/Hybrid 

revenue 

5% 

10% 

15% 

20% 

Services  in  support  of 
ccmcurrent  engineering 
environments 

$21M 

$40M 

$80M 

$120M 

%  of  EDA  services 
revenue 

3% 

5% 

8% 

11% 

Table  6.1  Market  Forecast  for  MCM  design  automation 

Calculations  used  in  Table  6.1  are  based  on  data  from  Datatfuest,  BPS  System  2000 
and  Harris  EDA  internal  proprietary  market  research  data. 

An  initial,  rough  order  of  nutgnitude  estimate  of  die  market  potential  for 
CHOICE  is  offered  in  Table  6.2  and  Figure  6.6. 


Software  License  fees  0.00 


0.00 

2.10 

2.73 

355 

4.61 

6.00 

7.80 

10.14 

0.00 

0.21 

0.27 

0.35 

0.46 

0.60 

0.78 

1.01 

0.00 

2.50 

3.25 

4.23 

5.49 

7.14 

9.28 

12.07 

0.00  4.81  6.25  8.13  10.57  13.74  17.86  23.22 


Tabk  6.2  CHOICE  Market  Forecast 
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Figure  6.6  Forecast  for  MCM  Concurrent  Engineering  Company 


The  following  assumptions  were  made  when  estimating  market  forecasts 
illustrated  in  Figure  6.6: 

1.  Additional  development  and  productization  as  proposed  in  this  Market 
Study  begins  by  January  1, 1994. 

2.  Commercial  company  has  technical  staff  capable  of  delivering,  training  and 
custom  software  development  services. 

3.  Support  of  ARPA  and  leading  electronic  systems  and  MCM  user  companies. 

4.  MCM  market  doubles  in  1994  and  follows  aggressive  revenue  growth  rates 
as  prqected  by  studies  referenced  in  this  Market  Study. 

5.  Potential  of  market  for  coivnirrent  engineering  environments  and  associated 
services,  as  calculated  in  this  Market  Study  are  correct.  It  is  recognized  by 
die  Program  Team  diat  has  assembled  dds  market  study  that  addition^ 
market  data  and  further  aiudysis  of  that  data  is  required. 

These  market  estimates  suggest  that  a  significant  opportunity  exists  for  a  corn* 
merdal  EDA  vendor  who  ofiers  a  concurrent  engineering  environment  for  MCM 
design  tools. 


ARPA  Market  Study —•  Maricet  Analysis 


Section  6  •  Page  8 


Market  Segments 

Eadt  electronics  segment  may  require  ^>ecific  functions  and  will  have  their 
unique  priorit)*  on  the  importance  of  each  feature.  A  summary  of  the  most 
important  features  requir^  for  each  segment  based  on  our  telemarketing 
survey  and  interviews: 

•  MCM  manufacturers  and  substrate  foundries. 

•  End-users  of  multivendor  design  autmnation  software  environments. 

•  End-users  of  single  vendor  design  autonuition  envirorunents. 

•  End-users  of  arudog  and  mixed  signal  MCMs 

•  Concurrent  operation  among  departntents  (electrical  design,  ir\echanical 
design,  product  assurance  material  planning,  purchasing,  etc.). 

•  Goverrunent  agencies. 
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Section  7  —  Commercialization 


Market  Positioning 

A  concuirent  en^neeiing  envircnunent  based  upon  a  ounmerdally  available 
object  oriented  database  will  have  specific  benefits  to  fite  markets  being  served. 
Success  of  die  product  dq)ends  t^>on  accurate  positioning  to  clearly  highlight 
die  unique  ben^ts  of  diis  environment  over  odier  similar  technologies. 

It  is  an  advantage  for  the  company  diat  markets  and  supports  this  technology  if 
it  also  markets  complementary  EDA  software.  However,  environments  offe^ 
by  broad  line  suppliers  force  end-user  customers  to  consider  the  software  tools 
ofiered  by  die  broad  line  supplier.  The  commercial  company  supporting  the 
concurrent  engineeiing  environment  must  be  applicaticm-neutral  for  the 
majority  of  die  EDA  applications  available  from  which  the  end-user  has  to 
choose. 

CHOICE  must  be  positioned  against  ccnmnerdally  available  EDA  frameworks. 
The  following  benefits  could  di^rentiate  CHOICE: 

•  The  use  of  STEP  international  standards  and  EXPRESS  as  the  basis  of  the 
CHOICE  envircnunent. 

•  Data  is  translated  automatically,  eliminating  time  ccmsuming  and  error 
prcme  manual  amversicm  of  data. 

•  The  end-user  and  MCM  manufrcturers  are  free  to  select  die  optimal  applica¬ 
tion  software  from  their  EDA  software  supplier. 

•  All  EDA  software  suppliers  must  compete  based  cm  functionality,  services, 
and  support  and  cannot  Icxdc-in  an  oid-user  to  inferior  tools. 

•  The  end-user  may  use  the  best  features  from  a  particular  tcxil.  For  example, 
an  autorouter  capable  of  haiuUing  a  specific  design  may  be  used  even  if  an 
MCM  CAD  toed  frenn  another  vendor  is  used  for  placement,  editing,  design 
rule  checking,  and  CAM  outputs. 

•  Existing  environments  diat  do  not  have  an  integrated  set  of  software  tools 
can  be  brought  together  and  made  to  operate  within  a  concurrent  engineer¬ 
ing  enviremment  The  end-users  are  able  to  preserve  dieir  investment  in 
so^are  tools,  each  of  which  may  be  very  capable  of  handling  specific 
design  functions,  and  yet  gain  die  advantages  of  supporting  a  concurrent 
engineering  design  medioddogy. 

•  Most,  if  not  all  commercially  available  products  employ  multiple  proprietary 
databases  and  provide  little  or  no  dir^  access  to  them.  The  CHOICE  con¬ 
current  engineerii^  environment  could  provide  a  window  into  these  "single 
vendor”  envirtmments  to  allow  die  addition  of  new  tools  or  the  integration 
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and  sharing  of  data  with  other  agendes  or  companies  dut  may  use  other 
tools. 

Cost  of  Marketing  and  Promotion 

The  level  of  promotion  of  CHOICE  that  is  required  to  realize  the  sales  projection 
in  dus  mark^  study  is  significant.  It  indudes  advertising,  trade  show  support, 
technical  arddes,  tedmology  seminars,  sales  literature,  and  the  collection  of  end- 
user  case  studies. 


The  actual  amount  invested  in  promoticm  varies,  depending  upon  the  overall 
business  plan;  however,  an  initial  allotment  of  $735,000  per  year  is  proposed  for 
marketing  and  promotion  (refer  to  Table  7-1). 


Advertising,  development  of  an  ad  campaign  and  ten 
placements  in  electronic  industry  trade  magazines. 

$60,000 

Trade  show  support:  Design  Automation  Conference,  four 
additional  trade  shows  for  five  total  indudes  fees,  travel 
expenses  and  promotion. 

$100,000 

Sales  literature  induding  product  descriptions,  customer  case 
studies,  services  descriptions  (design  and  printing). 

$30,000 

Technology  seminars  and  road  shows  with  product 
demonstrations.  Preparation  costs  and  the  cost  of  two  road 
shows  per  year  with  visits  to  eight  major  dties  during  each 
show  (preparation,  travel  and  expenses). 

$70,000 

Tedmical  artides  and  case  studies,  the  development  of 
partnership  programs,  sales  aids  induding  presentation 
materials. 

$25,000 

Product  demonstrations,  preparations  and  equipment 

$150,000 

Promotion  staff  salary,  benefits,  and  travel 

SmOQQ 

Total 

$735,000 

Table  7-1  Promotion 


Pricing 

Product  pricing  is  determined  by  the  pricing  for  similar  products  and  services 
available  in  the  commerdal  market  and  the  value  to  the  end-user.  Value  is 
measured  by  intangible  benefits  such  as  improved  engineering  productivity, 
reduced  design  cydes,  more  accurate  designs,  and  higher  quality  products. 
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The  product  could  be  delivered  in  a  modular  form  that  provides  maximum  cus¬ 
tomization  and  pricing  flexibility.  Operaticm  across  networks  will  be  assumed 
and  no  node  loclUd  pricing  will  be  considered. 

Pricing  is  prc^>osed  in  Table  7-2.  The  recommended  list  prices  are  comparable  to 
fees  charges  by  leading  EDA  suppliers  for  design  frameworks,  procedural 
languages,  data  toolkits  and  services: 


Product  offered: 

Fees  charged: 

The  basic  concurrent  engineering  environment  without 
applications  interfaces 

$5,000 

Each  applications  interface  allowing  for  bi-directional 
movement  of  data. 

$5000  per  unique 
interface 

Database  technology  used  within  the  concurrent 
engineering  enviroiunent 

STEPT(X>LS 

pricing 

Procedural  Interface  (PI)  pricing  including  PI  and 
debugging  tools 

$10,000 

Table  7^2  Product  Pricing 

Distribution 

CHOICE  requires  a  sophisticated  sales  process  that  requires  educating  the 
customer  and  strong  pre-  and  post-sales  technical  support.  Therefore  it  is 
recommended  that  scdes  will  be  directed  through  a  focused,  direct  sales  force  of 
highly  technical  sales  professionals  and  applications  support  teams.  OEM  resale 
agreements  may  be  considered  with  companies  involved  with  selling  EDA 
applications;  however,  one  must  avoid  sales  channel  conflicts. 

Services 

CHOICE  requires  a  high  level  of  technical  support.  The  company  that  markets 
CHOICE  is  also  responsible  for  multi-level  customer  traiiung,  installation,  soft¬ 
ware  support,  integration  services,  and  whatever  die  customer  requires  in  the 
form  of  support  services. 

The  commercial  company  must  be  expert  in  EDA  software  technologies,  data¬ 
base  technology,  engineering  productivity  issues,  and  MCM  technology. 
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Pr(^>05ed  pricing  for  services  are  provided  in  Table  7-3: 


Service  offered: 

Fees  charged: 

Software  support  including  software  upgrades  and 
tel^hone  hotline  (800)  service 

15%  of  the  software 
license  list  price, 
charged  annually 

Training  for  beginner,  intermediate,  advanced  levels. 

$1000  per  student 
per  course 

Integration  services  where  customer  specifies  the 
devdopment  of  additioiud  applications  interfaces,  new 
features,  customization  of  the  enviroiunent 

Quoted  per  job  at 
an  average  rate  of 
$125  per  hour 

Table  7-3  Services  Pricing 

Product  Packaging 

The  product  will  be  modular  to  allow  for  maximum  flexibility  and 
customization. 

Included  with  a  license  fee  is  product  user  guide,  systems  administration 
manual,  on-line  HELP  system,  and  a  90-day  warranty. 
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Section  8  —  Conclusions 

All  new  and  successful  software  technologies  address  a  specific  set  of 
end-user  problems.  This  Market  Study  has  identified  end-user  problems 
and  omcems,  and  it  is  dte  opinion  of  the  Program  Team  that  CHOICE 
could  be  positioned  to  resolve  or  lessen  these  problems.  The  information 
cdlected  in  this  Market  Study  highlights  issues  as  true: 

•  MCM  technology  is  being  adopted  by  most  leading  systems  electron¬ 
ics  companies. 

•  The  revenue  spent  on  MCM  technology  —  including  MCM 
assemblies,  MCM  design  automation,  and  manufacturing  equipment 
is  —  forecast  to  double  in  1994  —  and  may  reach  $10  billion  by  the  year 
2000. 

•  End-users  highlight  issues  involving  the  access  and  movement  of 
design-  and  component-data  as  th^  areas  needing  the  greatest 
amoimt  of  improvement  in  commercial  technology 

•  MCM  technology  has  added  a  level  of  complexity  that  requires  a  con¬ 
current  engineering  design  methodology  tl^t  depends  upon  efficient 
interaction  of  multi-disciplined  design  and  manufacturing  teams. 

These  statements  taken  together  identify  a  growing  market  that  has  an 
associated  problem  that  can  be  partially  resolved  with  the  availability  of 
a  commercial  product  based  on  the  CHOICE  coiunirrent  engineering 
enviroiunent. 

CHOICE  has  the  potential  to  satisfy  many  of  the  technical  and  product 
features  problems  that  tmderlie  these  statements.  The  market  forecasts 
suggest  diat  a  large  potential  reward  could  be  realized  by  any  company 
diat  is  prepared  to  invest  the  time  and  resources  necessary  to  produce  a 
commerd^-quality  product  that  satisfies  some  of  the  end-users'  needs. 

Government  assistance  through  the  DICE  program  has  produced 
valuable  core  software  technology. 

•  CHOICE  demonstrates  the  feasibility  of  integrating  multiple  EDA 
software  applications  to  allow  multi-disciplined  teams  to  work  in  a 
cooperative,  time-efficient  manner. 

•  CHOICE  uses  the  internationally  accepted  STEP/PDES  standard  and 
the  EXPRESS  modeling  language.  This  provides  for  comprehensive 
design  data  modeling  which  meets  or  exceeds  the  current  proprietary 
capabilities  offered  by  broad-line  EDA  suppliers  of  design  framework 
te^ology. 
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•  CHOICE  is  an  open  systems  that  can  share  data  among  proprietary 
MCM  design  tools. 

•  CHOICE  promises  end-visers  die  freedom  to  choose  die  best  and  most 
recent  tec^ology  for  individual  EDA  software  tools  by  eliminating 
problems  with  data  integration.  CHOICE  does  not  limit  the  scope  of 
die  data  model  and  allows  for  a  complete  data  transfer  limited  only 
by  die  capabilities  of  the  individual  software  application. 

•  CHOICE  is  highly  expandable  and  may  encompass  the  electronic 
design,  manufacturing,  and  mechanical  engineering  models  diat  are 
necessary  to  support  a  concurrent  engineering  approach  for  the 
cmnplete  MCM  design-  and  manufacturing-process. 

Other  programs  funded  under  DICE  have  also  provided  similar  benefits. 
For  example,  the  Manufacturing  Optimization  system  developed  by 
Raytheon,  demonstrates  the  ability  to  bring  manufacturing  teams  into  the 
design  process  at  an  early  stage  and  before  investment  is  made  in 
prototy]^  or  production-tooling. 

For  the  United  States,  marketplace  advantages  such  as  low-cost  product 
manufacturing,  higher  quality  products,  more  feature  rich  products,  and 
being  first  to  enter  new  markets  can  be  realized  partly  through  efficient 
and  effective  concurrent  engineering  methodologies  and  its  supporting 
software  technology. 

Commercialization 

Commercialization  of  CHOICE  will  require  additional  engineering  effort 
as  well  as  an  investment  in  a  product  launch.  It  is  propo^  that  further 
development  of  the  technology  be  completed  prior  to  committing  to  a 
commercial  product  laimch.  Tlie  additional  product  development  effort 
would  focus  on  the  issues  raised  by  end-users  and  would  validate  the 
technology  in  production  beta  test  sites. 

Once  proven  in  beta  test  sites,  a  commercial  EDA  conqiany  would  then 
be  much  better  positioned  to  justify  the  allocation  of  internal  funds  or 
could  raise  capital  for  a  product  launch. 

For  commercialization,  we  propose  that  additional  developmmt  efforts, 
as  outlined  in  the  following  sections,  be  completed. 


Freedom  of  data  among  ph3rsical  design  automation  tools 

CHOICE  must  be  demonstrated  to  be  capable  of  handling  a  broad  range 
of  MCM  technologies. 
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The  demonstration  of  tiie  CHOICE  environment  used  a  low-ten^rature 
cofired  ceramic  MCM  as  a  demonstration  vehicle.  Laminate,  silicon, 
chips*first  technology,  and  surface  mount  technology  examples  must  also 
be  proven  to  quorate. 

CHOICE  must  support  tite  products  offered  by  tiie  leading  MCM  design 
tool  vendors,  iivluding  Harris  EDA,  Cadence,  Mentor  and  Intergraph. 
Furtiier  development  could  produce  commercial  quality  interfaces  with 
products  from  each  of  tiiese  conqjanies.  The  MCM  application  model 
may  be  expanded  to  encompass  ph)r8ical  design  data  supported  by  all  of 
titeM  companies. 

The  development  of  an  application  model  for  MCM  physical  design  data 
should  be  submitted  to  the  intematicmal  standards  committee  (n\  STEP  to 
have  the  MCM  AP  endorsed  and  published. 

CHOICE  must  also  be  enhaxKed  to  include  the  functionality  of  ROSE 
DELTA  files.  ROSE  DELTA  files  are  used  for  data  management,  version 
control,  and  data  locking  features. 

MCM  Design  Kit  Process  Models 

The  CHOICE  environment  provides  functionality  to  create  Process 
Modeb  for  each  MCM  technology  and  each  MCM  supplier.  This  has 
been  demonstrated  for  printed  circuit  manufacturing  in  ti\e  Raytheon 
Manufiicturability  Optimization  program. 

MCM  design  is  dependent  upon  designers  understanding  the  specific 
manufacturing  and  assembly  rules  of  the  selected  MCM  technology  and 
supplier.  All  EDA  vendors  supplying  ph3r5ical  CAD  tools  are  building 
proprietary  Design  Kits  to  support  MCM  design. 

Process  Modeb  should  be  created  that  validate  tiie  design  data  against 
MCM  process  characterbtics.  These  Process  Modeb  would  provide  a 
central  location  for  Design  Kite  that  would  make  the  data  avaibble  - 
described  in  the  international  standard  modeling  language  EXPRESS  -  to 
all  MCM  CAD  toob  and  MCM  ixumufacturers. 

Support  of  standard  format  interfaces 

The  CHOICE  environment  supports  any  standard  that  can  be  repre¬ 
sented  in  EXPRESS.  Thb  capabiUty  could  be  demonstrated  for  EDIT  and 
IGES  based  on  tiie  ciurent  EXPRESS  representation  of  tiiese  standards. 
The  CHOICE  EXPRESS  model  must  be  expanded  to  include  the  portion 
of  tiie  EDIF  and  IGES  modeb  necessary  to  support  MCM  design. 

fri  addition  to  EDIF  and  IGES,  EXPRESS  modeb  should  be  developed  for 
the  following  formats: 
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The  Logic  Modeling  DEE  Format  being  developed  vmder 
ARPA/ESTO  ASEM  Contract  MDA972-93C. 


•  EDA  software  >  MCM  manufacturing  interface  formats  to  be  pro¬ 
posed  by  the  ASEM  CAx  Interface  Specification  Alliance  formed 
under  ARPA-^Jonsored  USAF  WL  Contract:  F33615-92-C-1134. 

Addition  of  data  validation  software  algorithms 

The  CHOICE  environment  assiunes  diat  data  integrity  is  maintained 
dirough  multiple  cycles  among  software  applications.  However,  end- 
users  are  gready  concerned  with  corrupted  design  data,  inconsistent 
data,  and  error  detecticm  and  correction.  Validation  is  required  for  the 
users'  peace  of  mind  and  to  avoid  cosdy  prototype  tooling  regardless  of 
die  level  of  quality  of  the  CHOICE  concurrent  engineering  environment. 

Harris  EDA  has  developed  Design  Integrity  Management  software  that 
validates  electronic  design  data  that  originates  horn  multiple  sources. 
The  Design  Integrity  Management  software  could  be  integrated  within 
CHOICE  to: 

•  Validate  die  data  originating  from  multiple  applications  programs 
including  EDA,  material  planning,  and  manufacturing. 

•  Alert  die  project  team  of  potential  inconsistencies  in  the  data. 

•  Correct  erroneous  data  and  update  the  individual  databases  of  the 
software  applications  that  are  i^uded  in  the  CHOICE  environment. 

•  Generate  a  history  of  changes  that  were  made  in  the  design  cycle. 

Addition  of  a  Graphical  Procedural  Interface  (GPI)  environment 

A  commercial  product  must  allow  end-users  the  option  of  programming 
and  integrating  software  applications  without  depending  upon  the  com¬ 
mercial  vendor.  An  easy-to-leam  and  easy-to-use  Graphical  Procedural 
Interface  must  be  made  available  to  diose  technical  users  who  are  not 
software  programmers  (i.e.,  designers,  electrical  engineers,  etc.). 

Increase  Scope  of  CHOICE 

CHOICE  could  also  be  expanded  to  further  demonstrate  the  feasibility  of 
developing  a  concurrent  engineering  environment  for  the  MCM  design 
environment  Specific  areas  of  ccmcem  identified  by  end-users  include 
MCM  test,  MCM  manufacturing  process  modeling,  and  system  simula- 
titm.  These  areas  would  expand  the  appeal  of  CHOICE  as  a  commercial 
product.  However,  dtey  should  not  be  considered  of  secondary  impor- 
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Integration  of  test  software  and  automatic  test  equipment 

The  integration  of  test  into  the  design  process  aiul  an  approach  that 
en^>hasizes  Design-for-Test  (DFT)  was  highlighted  by  numy  end-users. 
The  Hmris  GASD  Case  Study  in  particular,  points  to  die  importance  of 
including  test  issues  widiin  die  concurrent  engineering  environment. 

The  CHOICE  concurrent  engineering  environment  could  be  enhanced  to 
demonstrate  a  concurrent  design  and  test  environment  diat  includes: 

•  A  Test  Process  Model  diat  evaluates  die  testability  of  an  MCM  design, 
including  support  of  structural,  functional,  and  behavioral  test. 

•  Test  pattern  and  test  vector  generation. 

•  The  development  of  SCAN,  BIT  and  BIST  circuit  cells  and  standard 
test  component  descriptions  diat  could  be  maintained  in  die  CHOICE 
database  and  be  made  available  to  the  applications  that  are  integrated 
in  CHOICE. 

Addition  of  parts  and  nuterial  maiugement  Si.rt  are 

The  largest  gap  in  end-user  satisfaction  identified  by  die  survey  listed  die 
relative  importance  of  access  to  chip  data  with  what  is  currendy  avail¬ 
able.  The  Harris  GASD  Case  Study  highlighted  that  managing  materials 
and  parts  is  an  integral  part  of  the  concurrent  engineering  design 
environment. 

The  Approved  Parts  Interactive  Management  System  (APIMS)  provides  a 
general  database  widi  extensive  information  regarding  approved  suppli¬ 
ers  and  standard  parts  for  use  in  deliverable  hardware.  APIMS  is  tinted 
into  the  purchasing  organization  and  is  used  to  manage  con^ionent 
procurements. 

The  Parts  Control  and  Tracking  System  (PCATS)  manages  the  parts  list  at 
die  MCM,  PCB,  and  overall  system  leveb  for  each  assembly  within  a 
product  or  project. 

These  two  programs,  developed  by  Harris  GASD,  provide  valuable  func¬ 
tions  that  c^d  not  be  acquired  in  die  commercial  market. 

The  CHOICE  concurrent  engineering  environment  could  be  enhanced  to 
incorporate  APIMS  and  PCATS.  In  addition,  to  expand  the  scope  of  die 
CHOICE  irrqilementation,  we  propose  diat  the  Logic  Modeling  Corpora¬ 
tion  DIE  fmmat  specification  be  rr^eled  in  EXPRESS  to  ofier  a  complete 
part  description,  procurement  and  management  system  with  die  physical 
design  tools. 
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This  solution  provides  design  and  nuiterial  procurement  capability  that, 
to  die  best  of  our  knowledge,  does  not  exist  in  the  commensal  market¬ 
place.  Therefore,  diis  set  of  enhancements  has  dte  potential  to  be  a 
successful  commercial  product. 

Integration  of  an  MCM  design  optimization  system 

Design  Optimization  software  needs  to  be  developed  to  assist  systems 
engineer  in  partitioning  an  electronic  system  into  chips,  MCMs,  and 
printed  circuit  boards.  The  Design  Optimization  t»dmology  being 
devdoped  by  Harris  EDA  could  be  integrated  into  CHOICE  to  w  for 
system  floorplanning  concurrent  widi  MCM  CAD  layout 

Syston  floorplanning  will  select  cmx^xments  in  die  appropriate  surface 
mount  or  bare  die  f(»mat,  depending  upon  die  MCM  or  PCB  technology. 
The  Design  Optimization  teclmology  also  includes  Design  Advisors  diat 
calculate  routability,  electrical  delay  calculation,  and  dtermal  data. 

Application  of  a  concurrent  engineering  enviroruncnt  for  multileve 
and  ntixed  sigtuil  applications 

MCM  design  cannot  be  easily  simulated  due  to  dte  complexity  involved 
with  simulating  multiple  chips  interconnected  on  an  MCM.  CHOICE 
could  be  expanded  to  provide  an  application  model  for  MCM  simulation 
that  allows  omcurrent  operation  of  multiple  simulators  on  the  concurrent 
(parallel)  operations  of  a  sir^e  simulator  in  order  to  simulate  an  MCM. 

It  was  also  reported  and  highlighted  by  Harris  GASD,  duit  diere  is  a  lack 
of  synergy  between  analog  and  digit^  EDA  software  tools  that  causes 
difficulties  during  the  design  process.  Mamud  calculations  perfonrted  by 
analog  design  engineers  are  often  required. 

The  CHOICE  concurrent  engmeering  environment  will  support  ti\e  data 
required  for  both  analog  and  digital  simulation.  Integration  of  multiple 
simulators  tiuit  operate  on  a  single  database  could  r^eve  tiie  problem 
and  allow  for  concurrent  simulation  of  mixed  sigrud  MCMs. 


ARPA  Market  Study Conclusions 


Section  8  •  Page  6 


References 


The  following  references  provided  a  basic  foundation  for  dw  a  priori 
assun^ons  in  dus  report 

MCC  Technical  Report  Workshop  Summary  Report  on  Integrated 
CAD/CAE/CAM/CAT  Tools,  Standards  and  %>ecificatiorts  for  Electronic 
Multidiip  Module  Design  and  Manufacture  Held  12-13  December  1991,  Dallas, 
Texas 

System  Description  Document  for  die  Manufacturing  Optimization  (MO) 
System,  July  1993,  Raytheon  Corporation,  prepared  for  DARPA  omtract  number 
MDA972-92-C-0020. 

PC  AT  User's  Manual,  Harris  Government  Aerospace  Systems  Division,  Release 
2.0,  December  1, 1992 

PCAT  Manager's  Manual,  Harris  Government  Aerospace  Systems  Division, 
Release  2.0,  December  1, 1992 

Hardwick,  M.,  Mehta,  A.,  Spooner,  D  and  Willis,  C.,  The  Step  Programmer's 
Tool  Kit,  Tutorial  Manual,  STEP  Tools  Inc.,  Troy,  NY,  1992. 

Date,  C.J.,  An  Introduction  to  Database  Systems,  Fourth  Edition, 
Addiscn-Wesley,  Reading,  Mass.,  1986. 

Loomis,  M.E.S.,  The  Database  Book,  Macmillan  Publishing,  New  York,  NY,  1987. 

Dataquest  "Electronic  Design  Automation  Worldwide  Market  Share"  "Market 
Statistics  1993",  March  15, 1993,  Dataquest,  Inc. 

Dataquest  "Electronic  Design  Automation  Applications"  "Market  Trends  Market 
Oudook",  December  28, 1992,  Dataquest,  Inc. 

BPA  System  2000  Multichip  Modules  Survey  Report,  1993 

EDIF  Electronic  Design  Interchange  Format  Version  2.0.0, 1988,  EDIF  Steering 
Committee,  Electronics  Industries  Assoication 

Initial  Graphics  Exchange  Specification  (IGES)  Version  3.0,  U.S.  Department  of 
Commerce,  National  Buruea  of  Standards,  1987 


ARPA  Market  Study  —  References 


Section  9  •  Page  1 


